There are three practical ways to get software talking to QuickBooks Online: call the Accounting API yourself, put an MCP server in front of it, or wire it up in Zapier. They are not competing implementations of the same thing. The API is the ground truth and everything else sits on top of it. An MCP server is a translation layer that lets a language model call that API without you writing glue code. Zapier is an event-driven automation platform that happens to speak to QuickBooks among nine thousand other apps. Pick by what you are building, not by what sounds most modern.
Does QuickBooks have an API?
Yes. QuickBooks Online has the Accounting API, a REST interface (with a GraphQL surface alongside it) that uses standard HTTP methods and JSON. Its entities map onto what you see in the product: invoices, bills, customers, vendors, accounts, journal entries, plus report endpoints such as ProfitandLoss, GeneralLedger and CashFlow. Authorization is OAuth 2.0 against one company at a time, identified by its realm ID. Access tokens last 60 minutes and are renewed with a refresh token. Every developer account comes with a sandbox company, and you can create up to ten, each valid for two years. Going to production means publishing your app, and listing it in the QuickBooks App Store adds a three-part review. Rate limits apply: 500 requests per minute per realm ID, 10 requests per second, and an HTTP 429 when you exceed them. QuickBooks Desktop is a separate product with its own QBXML SDK, not this API.
Path one: the raw QuickBooks Online Accounting API
What you get is everything. Intuit's overview of the Accounting API lists every entity, every report, sparse and full updates, soft deletes on lists and hard deletes on transactions, a SQL-like query language, batch requests, and change data capture for polling what moved since a timestamp. Nothing sits between your code and the ledger.
What you pay for it, in order of how much it will surprise you:
An Intuit app and an OAuth flow. You register an app on the developer portal, get a client ID and secret, and implement the authorization code grant. Production requires a public HTTPS redirect URI. Sandbox will accept http://localhost. Testing is free and reasonably pleasant: a sandbox company arrives with your developer profile, you can make up to ten, and each lasts two years.
Token refresh, done properly. Intuit's OAuth guide puts access tokens at 3,600 seconds and tells you to always store the latest refresh token from the most recent server response, before the 100 days expire. Read that twice. The refresh token you hold is replaced every time you use it, so two processes refreshing at once can overwrite each other with a stale value and knock the customer offline until they reauthorize. On serverless, where two invocations firing together is normal rather than exotic, you need compare-and-swap on the stored token instead of a plain write.
Minor versions. Intuit versions the schema and retires old versions. Support for minor versions 1 through 74 was discontinued from 1 August 2025. A request that omits the parameter, or asks for anything below 75, now gets minor version 75 whether that is what your parser expects or not.
Rate limits and payload limits. From Intuit's limits and throttles page as of September 2026: 500 requests per minute per realm ID, 10 per second per realm and app, 429 with a 60 second backoff when you cross the line. Queries return at most 1,000 entities, so you paginate. Batch requests are throttled at 40 per minute and Intuit recommends no more than 30 payloads in one.
App review, if you list. Publishing makes the app live. Listing it on the QuickBooks App Store triggers a three-part review that you have to pass in full. Worth knowing before you plan a launch date: as of September 2026 the Intuit App Partner Program is open to partners based in the US, the UK, Australia and Canada, with Quebec excluded.
A connection per company. Everything is scoped to a realm ID. Five clients means five OAuth grants, five token sets, five refresh schedules.
None of that is hard. It is a week or two of work, then maintenance forever.
Path two: an MCP server
The Model Context Protocol is a small standard for exposing tools to a language model. A server publishes a list of tools, each with a name, a description and a JSON schema for its arguments. The client hands that list to the model. The model picks one, fills in the arguments, and the server executes it and returns the result. That is the whole idea. The value is that the model calls your API directly, with no code between the question and the call, and no prompt engineering to teach it the request format.
Two shapes exist for QuickBooks.
Self-run. Intuit publishes an open-source server at intuit/quickbooks-online-mcp-server, MIT licensed, 145 tools over 29 entity types and 11 financial reports. It runs as a local stdio subprocess on your machine. Its README is explicit that you still need your own Intuit app and a browser-based OAuth handshake first, that production needs a public HTTPS callback, and that it runs unattended afterwards until the 100 day refresh window lapses. It takes one realm ID from the environment, so it is one company per configured process. Write tools can be suppressed with environment flags.
Hosted. Caribooks is the hosted shape: sign in, authorize QuickBooks once in a browser, add the connector to Claude or ChatGPT. No developer account, no server, no token handling. 211 tools including 35 reports, several companies under one account with a company parameter to pick one. There is a guide on the no developer account route and one on wiring it into ChatGPT.
What an MCP gives an agent that the raw API does not: a tool list the model can read and act on immediately. You do not write a function-calling schema for get_profit_and_loss, you do not parse the model's intent into a report request, you do not handle the 429. You describe the job in a sentence and the model does the picking.
What it does not give you: bulk ETL, webhooks, or a queue. MCP is request and response, driven by a model, in a conversation. It is not a pipeline. If you need every transaction since Tuesday loaded into a warehouse at 3am, an MCP server is the wrong shape and change data capture on the raw API is the right one.
Path three: Zapier or Make
Zapier is event-driven automation between applications. A trigger fires, actions run. Its QuickBooks Online integration has triggers for new accounts, bills, expenses, customers, estimates and bank transactions, and actions like Create Invoice, Create Customer, Create Expense and Find or Create Customer. QuickBooks Desktop is not supported, and you need a QuickBooks Online subscription on the account you connect.
Pricing is by task. A task is a successfully completed action, and triggers are free. As of September 2026 the free tier includes 100 tasks a month, and tasks are shared across everything you run on the platform: Zaps, AI steps, code steps, the SDK, and MCP.
Zapier also ships its own MCP server, available on all plans, exposing the same catalog to Claude, ChatGPT or Cursor. Its pricing page states that one MCP tool call uses two tasks from your plan's quota. That is fine for a handful of agent actions a day and expensive as a way to read reports, because a single accounting question can easily be five calls.
Make is the same category with a different builder, metered in credits rather than tasks. Its free plan is 1,000 credits a month with a fifteen minute minimum interval between runs, so the shape of the trade is the same even though the unit is not. The reasoning below applies to both.
Which one for which job
| What you are building | Raw API | MCP server | Zapier or Make |
|---|---|---|---|
| A customer-facing product | The only real answer. You need control over errors, retries and the token store | Fine as an internal tool inside that product, not as its data layer | No. You cannot ship a Zap as your product |
| An assistant for an internal team | Weeks of work for a chat box you did not need to build | This is the case it exists for. Hosted if nobody wants to run a server | Works, but every question costs tasks and the answers come back as automation output |
| Syncing to another SaaS | Right if the mapping is complicated or the volume is high | Wrong shape. No triggers, no schedule | The obvious choice. Trigger, map fields, done |
| A nightly data export | Right, with change data capture and pagination | Wrong shape. Nothing runs on a cron | Possible, but you will burn tasks per record |
| A one-off migration | Right, and probably a throwaway script | Usable for a small one, awkward for a large one | Fights you on volume and on error handling |
OAuth and read metering, explained
Two things trip up first builds.
OAuth is per company, always. There is no account-level token that sees every client's books. Each QuickBooks company grants access separately and gives you a token bound to its realm ID. A bookkeeping firm with 30 clients has 30 grants to obtain, store, encrypt and refresh. Caribooks handles that per connection and starts every connection read-only until the account owner turns writes on. We would tell anyone building this themselves to do the same.
Reads are metered. Intuit's limits page states that apps in the Builder tier of the Intuit App Partner Program have an included limit of 500,000 CorePlus API calls per workspace per month, and that calls beyond it are throttled with a 429. That is a monthly ceiling on the whole app, not per customer, which changes how you think about caching and about chatty agents. A model that pulls a whole general ledger to answer a question about one vendor has just spent a few hundred calls on a number two calls would have given you, and nothing in the transcript says so. We monitor global usage daily and alert well below the ceiling, and there is no per-question fee on any Caribooks plan. If you build your own, put a counter in from day one.
Building your own agent on top of an MCP
If you are writing the agent loop yourself rather than using Claude or ChatGPT as the client, the shape is small:
connect to the MCP server over HTTP with an OAuth token
list tools, keep only the ones this agent needs
send the user's question plus that tool list to the model
loop: model returns a tool call -> execute it -> feed the result back
stop when the model answers in prose
One practical note on tool count. Caribooks exposes 211 tools. That is deliberate for a general assistant, where you cannot predict whether someone will ask for a trial balance or a vendor credit. It is the wrong number for a purpose-built agent. A model choosing among fifteen relevant tools picks better and cheaper than one choosing among two hundred, and clients differ in how many they will surface at once. Filter the list on your side to the job at hand: an invoice-chasing agent needs get_aged_receivables, search_invoices, get_customer and send_invoice, and nothing else.
Where this is the wrong tool
You are shipping a product that writes to customers' books. Use the API. An MCP server puts a language model in the write path, and for anything transactional you want deterministic code, idempotency keys and your own retry logic.
You need webhooks or a schedule. Neither MCP nor a chat client has an event loop. Intuit's change data capture on the raw API, or a Zapier trigger, is what fires without a human asking.
High volume, tight budget. Paying two tasks per tool call, or paying an LLM to read a report you could have queried, is the expensive path to a number. Query it directly.
QuickBooks Desktop. Different product, different technology. The Desktop SDK speaks QBXML to software installed on the same machine or local network, and none of the three paths above reach it.
If nothing is connected yet and you want to try the MCP path before committing engineering time to the API, connecting QuickBooks to Claude takes a few minutes and starts read-only, so you can find out what a model actually does with a ledger before you decide what to build. The MCP overview covers what the tools are and how the access levels work.