QuickBooks API rate limits explained: 500 requests per minute, the 10 concurrent connection cap, batch limits and how to stop 429 errors
11 min read Integration The Adapters team
Last updated August 2026
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
QuickBooks Online throttles the Accounting API at 500 requests per minute per company file and allows at most 10 concurrent connections to it. Almost every 429 we get asked about is the second limit, not the first, which is why adding workers makes a slow QuickBooks sync slower. Here are the current numbers, read from Intuit developer documentation on 22 August 2026, the five different failures that all show up as one problem, and the six changes that fix them.
Key takeaways
- 500 requests per minute, per realmId. Scored per company file rather than per app, and batch requests count toward it.
- 10 concurrent connections is the real ceiling. Scored on the app and realmId combination. This is the limit most integrations breach first, while nowhere near 500 a minute.
- Batch up to 30 operations per request. Thirty times fewer calls for the same work, with its own separate ceiling of 40 batch requests a minute.
- A query with no MAXRESULTS returns 100 rows. No error, no warning. Set MAXRESULTS 1000 and page with STARTPOSITION.
- Alert on errorCode 003001. HTTP 429 with message ThrottleExceeded. The status code alone does not tell you which ceiling you hit.
What are the QuickBooks API rate limits?
Intuit throttles the QuickBooks Online Accounting API at 500 requests per minute per realmId, including batch requests, and permits a maximum of 10 concurrent connections to the same realmId. Both are scored on the application and company file combination rather than per application overall. Breaching either returns HTTP 429 with errorCode 003001 and the message ThrottleExceeded.
The detail that matters more than either number is the word realmId. The allocation belongs to the company file, not to your app, so if a client is already running a payroll connector and a receipt app against the same QuickBooks company, you are sharing that budget with software you do not control and cannot see. An integration that behaves perfectly in your sandbox can throttle immediately in a customer account for reasons that have nothing to do with your code.
QuickBooks Online API limits at a glance
| Limit | Value | Detail |
|---|---|---|
| Requests per minute | 500 per realmId | Scored per company file, not per app. Batch requests count toward it. Two integrations on one company share the budget |
| Concurrent connections | 10 per app and realmId | The ceiling most teams actually hit. Scored on the app and realmId combination, so parallelism is capped per company |
| Throttle response | HTTP 429, errorCode 003001 | Message reads ThrottleExceeded. This is the one error code every QuickBooks pipeline should alert on by name |
| Operations per batch request | 30 | Creates, updates, deletes and queries can be mixed in one call. The single biggest throughput lever on this API |
| Batch requests per minute | 40 per realmId | Batches carry their own tighter ceiling on top of the 500. Thirty times forty is still 1,200 operations a minute |
| Query default page size | 100 records | A plain SELECT returns 100 rows and gives no signal that more exist. The most common silent data-loss bug on this API |
| Query maximum page size | MAXRESULTS 1000 | The per-request ceiling. Page with STARTPOSITION and always request the full 1000 to spend fewer calls |
| Change data capture response | Up to 1,000 objects | CDC has no pagination. Above 1,000 changes you shorten the window, you cannot page through it |
One honest note on sourcing. Intuit publishes these figures across several places: the API call limits and throttling article carries the 500 and the 10, the batch endpoint reference carries the 30 and the 40, and the query guidance carries the 100 default and the 1000 maximum. The change data capture retention window is the one value we would not print a number for. The endpoint clearly rejects a changedSince older than a fixed window with an unsupported operation error, but the exact day count is not stated in the endpoint reference the way the others are, so treat CDC as a mechanism for staying current and never as a way to reach history.
Why does my QuickBooks integration return 429 when I am under 500 requests per minute?
Because you breached the concurrency ceiling rather than the rate ceiling. Ten simultaneous connections per app and realmId is a hard cap, and it is easy to exceed at very low request volumes: twenty threads each making one slow call are twenty in-flight connections even though they total twenty requests a minute. Cap in-flight requests at ten per company file and the 429s stop.
This is the single most useful thing to know about this API, and it is the reason a QuickBooks sync often gets slower when you scale it out. Every worker past the tenth produces a throttle, which produces a retry, which produces another in-flight connection. The pool spends its time colliding with itself. Teams then conclude QuickBooks is slow and buy a bigger box, when the correct change is a semaphore with ten permits.
The five failures that all look like one problem
A 429 from QuickBooks does not tell you which ceiling you hit, and two of the failures on this list do not produce an error at all. Distinguishing them once, in your error handling, saves the same debugging session repeating every quarter.
| Failure mode | What you see | Actual cause | The fix |
|---|---|---|---|
| Rate exceeded | 429 after sustained traffic | More than 500 requests in a minute against one company file | Slow the request rate, or pack more work into each call with the batch endpoint |
| Concurrency exceeded | 429 while well under 500 per minute | More than 10 requests in flight at once to the same realmId | Cap the worker pool at ten per company file. Adding throughput will not help, it makes it worse |
| Batch ceiling | 429 on batch calls specifically | More than 40 batch requests a minute against one realm | Fill each batch to 30 operations rather than sending more, smaller batches |
| Silent truncation | No error at all, missing rows | A query with no MAXRESULTS returned only the first 100 records | Always set MAXRESULTS 1000 and page with STARTPOSITION until a short page comes back |
| Expired authorization | 401, then nothing syncs | The OAuth refresh token expired or was revoked | Rotate refresh tokens automatically and alert a human when reauthorization is needed |
Silent truncation is the row worth reading twice, because it is the only one that never surfaces as an incident. Every request returns 200, the dashboard is green, and the integration has been delivering the first hundred invoices of every query for eight months. Nobody finds it until someone reconciles a total by hand.
How many records can a QuickBooks query return?
A query returns 100 records by default and a maximum of 1000 when you set MAXRESULTS. To read more than that you page with STARTPOSITION, which is one-indexed, requesting 1000 rows at a time until a page comes back shorter than the page size. There is no cursor and no next-page token, so ordering matters if records are being written while you page.
That default of 100 causes more real data loss than every rate limit on this page combined, precisely because it is not an error. The API is doing what it documented; the integration simply never asked for more. If you are auditing an existing QuickBooks pipeline, grep for query strings without a MAXRESULTS clause before you look at anything else.
How do you avoid QuickBooks API rate limits?
Six changes, in the order they pay off. The first two account for most of the improvement in nearly every QuickBooks integration we have looked at, and neither costs anything.
Fix 01
Cap concurrency at ten per company file before you tune anything else
This is the fix that resolves most QuickBooks 429s, and it is counterintuitive because it means doing less at once. Intuit allows a maximum of ten concurrent connections to the same realmId, scored on the app and realmId combination. A worker pool sized for throughput, say thirty threads, breaches that ceiling continuously while sitting nowhere near 500 requests a minute. The symptom is a pipeline that gets slower the more workers you add, because every extra thread produces another 429 and another retry.
Fix 02
Use the batch endpoint and fill it to thirty operations
The batch endpoint accepts up to 30 operations in a single request, and it will happily mix creates, updates, deletes and queries in one call. A tool that writes one invoice per request is thirty times slower against exactly the same allocation. Fill each batch. Sending sixty half-empty batches instead of thirty full ones also walks you into the separate 40 batch requests per minute ceiling, which is the failure mode of teams who discovered batching and then used it timidly.
Fix 03
Always set MAXRESULTS, because the default silently truncates
A query with no pagination clause returns 100 records and does not tell you there were 4,000. Nothing errors, every request returns 200, and your warehouse quietly holds 2.5 percent of the invoices. Set MAXRESULTS 1000 on every query, page with STARTPOSITION, and keep going until a page comes back shorter than the page size. If you inherit an integration and want one thing to check first, check this.
Fix 04
Filter server side in the query, not in your own code
The query language supports WHERE clauses on fields including MetaData.LastUpdatedTime, which is what makes an incremental sync cheap. Pulling every invoice and filtering by date in your own code spends the allocation on rows you throw away. On a company file with years of history that is the difference between a nightly sync that finishes in a minute and one that is still running when the bookkeeper logs in.
Fix 05
Subscribe to webhooks instead of polling for change
Polling every few minutes to catch the handful of records that changed spends a per-minute budget on discovering nothing happened. QuickBooks webhooks notify your endpoint when named entities change in a connected company, and receiving one costs you nothing against the allocation. You still call the API to fetch the changed record, so this reduces the polling traffic rather than eliminating API calls, which is usually the larger half anyway.
Fix 06
Back off exponentially on 003001 rather than retrying straight away
An immediate retry after a throttle lands in exactly the same wall and burns another request doing it. Back off with increasing delay and jitter, and log the error code rather than just the status. HTTP 429 alone does not tell you whether you breached the rate ceiling, the concurrency ceiling or the batch ceiling, and the remedy is different for each. Recording errorCode 003001 with the in-flight request count at the moment it fired turns that guesswork into a one-line answer.
Does QuickBooks have change data capture?
Yes. The Accounting API exposes a changedatacapture endpoint that returns objects modified since a timestamp you supply, across a list of entities in a single call. It is the cheapest way to keep an existing sync current, because one request can tell you what changed across invoices, payments, customers and items at once instead of polling each entity separately.
Two constraints shape how you use it. A CDC response carries up to 1,000 objects and has no pagination, so if more than that changed in your window the answer is to shorten the window rather than to page through the result. And the endpoint rejects a changedSince older than Intuit's fixed retention window outright. CDC keeps you current; paged queries with STARTPOSITION are how you get history. Building a backfill on CDC works in testing against a fresh sandbox and fails against a company file with five years in it.
Can you increase QuickBooks API rate limits?
Not by paying for it. Intuit does not sell a rate limit add-on the way some platforms do, so the only levers are efficiency: fewer, fuller requests, server-side filtering, batching to thirty operations, and staying inside ten concurrent connections. For nearly every integration those levers are worth more than a paid increase would be anyway.
Before treating throughput as the problem, work out which ceiling you are actually hitting. More parallelism does nothing for a rate limit and actively harms a concurrency limit. More batches do nothing once you are at 40 batch requests a minute, though fuller batches still help. And nothing at all fixes a query that silently returned its first hundred rows. Log the error code, the in-flight count and the requested page size for one day, and the answer stops being a matter of opinion.
How many API calls does a QuickBooks sync actually use?
Do the arithmetic before you buy anything, because it is usually reassuring. A nightly incremental pull of everything changed in a mid-sized company file in the last 24 hours is typically a single CDC call plus a handful of paged queries: single digits, finishing in seconds against a 500 per minute budget. The job that hurts is the first one, the full history load, and that is pure arithmetic. Fifty thousand transactions at 1000 rows a request is 50 calls to read, and writing them into another system at 30 operations per batch is roughly 1,700 batch calls, which at 40 batches a minute is about 42 minutes of wall clock. Not fast, entirely predictable, and worth knowing before you promise a date.
Which is why the useful question on a vendor demo is not how many connectors they have. It is whether the connector caps concurrency at ten per company file, whether it fills batches to thirty, and whether every query sets MAXRESULTS. A vendor who cannot answer those three is spending a budget they do not measure. We keep the full set of limits tabled alongside the platforms that have to live inside them on QuickBooks integration tools.
Where rate limits fit in a working QuickBooks integration
Rate limits shape three decisions and are irrelevant to the rest. They decide whether you poll or subscribe, whether history comes from paged queries or from somewhere else entirely, and how many workers you are allowed to run. The account mapping, the conflict rule and the schedule are unaffected by any of it, and those are the decisions that determine whether the books actually reconcile.
It is also worth remembering how much financial data never touches the API at all. Bank and card activity arrives through feeds or as files, and when a bank will not connect to a feed the practical route is still to turn the exported CSV into a QBO file QuickBooks will import, which sidesteps the Accounting API entirely and therefore sidesteps every limit on this page. Knowing which half of your data goes through the API and which half does not is the difference between a capacity plan and a guess.
For the routes that do go through the API, the mechanics including the incremental filter that keeps a nightly load small are covered in Stripe to QuickBooks and Shopify to QuickBooks. For the warehouse direction, where you are reading in bulk on a schedule rather than writing conversationally, see QuickBooks to Snowflake. If the destination platform has its own tight allocation, and accounting platforms usually do, the same care applies at the far end: the Xero API permits only 5,000 calls a day per connected organization, which is a much smaller number than QuickBooks gives you in ten minutes.
Sync QuickBooks without babysitting the throttle
Concurrency capped where Intuit caps it, full batches, paged queries that never truncate, and per-record error logs you can actually read. Flat from $49 a month.
No credit card required.