QuickBooks API Integration built to survive the 2026 migrations

Almost always refresh-token rotation handled incorrectly. The access token lasts 60 minutes, and the refresh token — historically valid 100 days — changes value every 24 to 26 hours. Each refresh may return a new refresh token and immediately expires the previous one. Store the old one and reuse it and you get invalid_grant, which revokes the chain and forces the customer to reauthorise by hand. Two concurrent refreshes with the same old token will also invalidate each other, so the write needs to be atomic.

The documented figure is 500 requests per minute per combination of realm ID and app — per app-and-company pair, not per app globally. The batch endpoint moved to 120 requests per minute per realm ID in production on 31 October 2025, which replaced an earlier 40 per minute limit that many third-party guides still cite incorrectly. Throttling returns HTTP 429 with errorCode 003001. Sending a requestId with each call matters, because replaying the same requestId after a 429 replays the request rather than duplicating it.

Several things, and the dangerous ones are silent. Row index positions are no longer stable, so code addressing rows by position reads wrong values rather than erroring. Nulls return as empty strings instead of being absent. Child accounts always nest under parents. The qzurl deep-link field is removed. Day-summarised reports cap at 200 columns with the rest bucketed as "Others". Only 29 standard reports are supported. The deadline is 31 August 2026 and you can test now with the testing_migration parameter.

Under the App Partner Program, writes are free while reads, queries, reports and Change Data Capture are metered. The free Builder tier includes 500,000 metered credits per month, and the important detail is that overage is blocked rather than billed — so a production sync simply stops rather than costing you money unexpectedly. Paid tiers scale from there. Only successful responses are metered. Worth modelling before you build, because webhook-triggered follow-up calls consume credits as well as rate limit.

No, and it is not a limitation of our build. Bank-feed transactions sitting in For Review are not accessible through the QuickBooks API at all. Anything built on the API operates on posted transactions only. This genuinely constrains what "real-time" can mean for bank data, and any vendor promising otherwise is either using a different data path or overstating it.

For production keys against live company data, yes — Intuit's App Assessment Questionnaire covers legal, technical and security questions and takes most teams under an hour. Development keys do not work against live companies and production keys do not work in sandbox, which catches people out. A separate App Store listing review applies only if you are publishing publicly, and that averages around 20 days. We handle the questionnaire as part of the build.

Monitoring and alerting on token refresh failures and sync gaps, response to Intuit API changes including the dated 2026 migrations, and schema changes on your destination. This is the part software vendors structurally cannot sell you, because their product ends at the integration boundary. An integration is an operational commitment, not a delivery.