QuickBooks Online and Xero APIs: what a real integration involves
Both platforms hand you OAuth 2.0 and a working developer portal. What separates a real build from a demo is what happens to a posted entry after the API call succeeds.
Answered in short
5 things that decide this
- 01QuickBooks Online's API runs on OAuth 2.0 through Intuit's developer platform, with a registered app, a sandbox company for testing, and a review step before an app can move from development to full production access.
- 02Xero's API also runs on OAuth 2.0, connecting to one or more organisations a user authorises, and Xero publishes its own developer portal with app registration and review for apps used outside a single company's own books.
- 03Both platforms enforce rate limits per app and per connected company, so a sync built for one firm's transaction volume needs to be tested against a busier one before it ships.
- 04Neither platform's API decides what gets posted. A real build for a firm adds the review step: a bookkeeper or the CPA of record sees what an automated process wants to post before it lands, on anything beyond a routine, pre-approved category.
- 05We confirm the exact scopes, sandbox behaviour and rate ceiling for your setup during the audit, since a firm running third-party apps or a multi-entity structure sees a different picture than a fresh developer account does.
The access model isn't the obstacle here
Ask about ServiceTitan or Applied Epic, and the answer starts with who has to approve your app. Ask about QuickBooks Online or Xero, and that part is almost a non-issue. Intuit and Xero both publish developer portals anyone can sign up for. Both document their OAuth flow in public. Both give you a sandbox company to build against before you touch a real client's books.
That openness is exactly why your real risk sits somewhere else. When access is this easy, it's tempting to treat the whole project as plumbing: connect the API, move the data, done. But what actually decides whether the build is safe is what happens to a transaction in between. Your code reads it, then it posts to the ledger. What happens in that gap is the real question.
What each API actually requires
QuickBooks Online: register an app in Intuit's developer account, and you get OAuth 2.0 client credentials plus a sandbox company loaded with sample data for testing. Moving from development keys to full production access goes through an Intuit review. Your own firm's books connect fine on development keys. A product meant to serve many client companies needs that production step first.
Xero works the same way. OAuth 2.0 runs through Xero's own developer portal, and an app connects to one or more organisations a user explicitly authorises during that flow. A private app serving your own organisation is simple to stand up. A public app meant for other firms' clients goes through Xero's own review before general release.
Both platforms rate-limit calls per app and per connected company. A batch job pulling a year of transactions for reconciliation needs to be paced, not fired in one pass. We confirm your account's specific scopes and rate ceiling during the audit. A firm already running other connected apps sees a tighter picture than a clean developer account does.
- Client document arrivesIntake point, not a shared inbox nobody owns
- Extraction and categorisationThe model reads and proposes; it does not decide
- Reviewer sign-offA bookkeeper or the CPA of record approves before posting
- Post via QBO/Xero APIOnly after sign-off, logged with what was approved
- Close checklist and reportingReporting reads the ledger; it never writes to it
The API call is the easy half. The review gate around it is the build.
Client documents in, a posted entry out, with a person in between
When you ask for a QuickBooks Online or Xero integration, you're usually asking for one of three things. Get client documents into the ledger without re-keying. Run the close checklist against real numbers, not a spreadsheet copy. Or pull reporting neither platform's native dashboards build. All three start from the same document: a receipt, a bank statement, a vendor invoice a client emailed in.
The model's job in that chain is reading the document and proposing a categorisation and an amount. It doesn't decide what your books say happened. A routine, pre-approved posting, like a recurring vendor charge matched to the same category for a year, can run on a lighter review than a new vendor or an unusual amount. Where that line sits is your call, not the API's.
Reporting sits on the other side of that line entirely. A dashboard reading QuickBooks Online or Xero data to show margin by client or work-in-progress never needs write access at all. Build it read-only, and you remove an entire category of risk from day one.
- 01Client documents typed into the ledger once, by a reviewer, not by the same data entered three times across systems.
- 02Close checklist automation that pulls real bank feeds and flags exceptions, instead of a person reconciling by memory.
- 03Reporting built read-only against the ledger, so a dashboard can never be the thing that posts a bad number.
Some of the systems we have shipped
Related questions
01Can a firm build this without hiring a developer?+
Off-the-shelf connectors handle simple one-way syncs between QuickBooks Online or Xero and a handful of common apps, so part of it, yes. A build that needs review gates, custom categorisation logic, or a reconciliation across your practice management tool usually needs custom work. The off-the-shelf connectors don't expose that level of control.
02Does QuickBooks Online or Xero charge extra for API access?+
Neither platform publishes a required paid tier specifically for API access in their own developer documentation. Treat a specific number a vendor quotes you as a claim to verify against your own account, not a fact to assume.
03Is Xero or QuickBooks Online easier to integrate with?+
Both run on OAuth 2.0 with a public developer portal and a working sandbox, and neither is meaningfully harder to reach than the other. The real difference shows up in your firm's specific setup: which one your clients already use, and which add-on apps are already connected to the account.
04What happens if a client runs QuickBooks Desktop instead of Online?+
Desktop is a different product with a different, older integration model, not the same OAuth API. If a client's books live in Desktop, we confirm what's realistic to build against during the audit rather than assuming the Online API applies.
05What does Hashlogics actually do on a project like this?+
We start by confirming exactly what your firm's QuickBooks Online or Xero setup exposes, what other apps are already connected, and where the review gate needs to sit for your workflow. That happens during the audit, against your own account, before anything gets scoped or built.
Related
- Custom software for accounting, insurance and staffing firms →Where an integration like this fits inside a wider back-office build.
- AI, automation and custom software for firms →What we build across accounting, insurance and staffing operations.
- Is AI automation worth it for an accounting firm? →The wider case for automating a firm's back office.
