Q.What Do You Need to Know Before Connecting Software to QuickBooks Online?
Four things: it is done through Intuit's REST API with OAuth 2.0, a free sandbox exists so nothing has to be tested against your live books, a private integration for your own company does not need Intuit's App Store review, and there is a 100-day inactivity rule that will silently disconnect you if nobody thinks about it.
Everything else written on this subject is written for developers. This is the same ground for the person signing the invoice — what to ask for, what will break, and what "integrated with QuickBooks" should mean in a quote.
All the specifics below come from Intuit's own developer documentation, read in September 2026.
How the Connection Actually Works
Your software talks to the QuickBooks Online Accounting API — a REST API, currently version 3. Authorization uses OAuth 2.0, and in Intuit's words it "is essential for both testing via sandbox companies and production apps." There is no password-in-a-config-file option, and that is a good thing.
What it means in practice: at some point a person with admin rights to your QuickBooks company clicks through a consent screen in a browser and authorizes the connection. From then on the software holds two tokens rather than a password.
The 100-Day Rule Nobody Mentions Until It Bites
This is the single most useful thing on this page, so it gets its own section.
Intuit's tokens work like this, verbatim from their documentation:
- "Access tokens are valid for 3,600 seconds (or one hour)."
- "Refresh tokens are valid for 100 days. This expiry date is rolling and gets extended each time it's used to refresh an access token."
- "All refresh tokens have a maximum validity period of five years."
And then the part that catches people:
"If the refresh token hasn't been used in the last 100 days, meaning a user hasn't connected to your app and thus no API calls have been made, the refresh token expires. Your app's access to the QuickBooks company terminates. Users will need to sign in and authorize your app again."
So an integration that goes quiet — a seasonal portal, a system used only at month end, a staging environment, anything paused over a slow quarter — will disconnect itself, and the fix requires a human with QuickBooks admin rights to re-authorize. It is not a bug and there is no way around it, but it is entirely avoidable with a scheduled call that keeps the token alive and an alert when it fails.
Two questions for your vendor: does anything keep the token refreshed when the system is idle, and who gets told when the connection drops? If the answer to the second is "the customer will notice when the orders stop syncing," that is the wrong answer.
There is also a five-year hard ceiling, which is worth writing on a calendar somewhere.
Want this looked at for your operation?
Twenty minutes on a call, and you'll know whether this is worth building, buying, or leaving alone. No deck, no pitch.
Book twenty minutesYou Can Test Without Touching Your Real Books
Intuit gives every developer account a free sandbox company:
- "When you create your developer profile, you automatically get a sandbox company."
- "You can create up to 10 sandbox companies. They're valid and active for two years."
- "Sandbox companies are region-specific. You can't change this later on."
This matters commercially. There is no legitimate reason for anyone to develop an integration against your live accounting data, and you should ask directly whether they are using a sandbox. Note the region lock — a sandbox created for the wrong country cannot be changed later, which is an easy and annoying mistake on a US-and-India project.
The Limits That Shape How It Behaves
These are the numbers that decide whether a sync feels instant or takes an hour, and they are worth knowing so a quoted approach makes sense to you.
| Limit | Figure |
|---|---|
| Requests per minute | 500 per company |
| Requests per second | 10 per company, per app |
| Records returned per query | "The maximum number of entities returned in a query response is 1000" — more needs pagination |
| Batch requests | "Recommended maximum number of payloads in a single batch request is 30", throttled at 40 batch requests per minute |
| When you hit the limit | "You'll see HTTP Status Code 429 when throttling occurs. If you see this, wait 60 seconds before retrying" |
| Request timeout | "Any requests that take longer than 120 seconds to execute will time out" |
| Line items per transaction | 10,000 (except journal entries) |
The practical consequence: a first-time import of several thousand customers and items is not instant, and a well-built integration batches, paginates and backs off rather than hammering. If a vendor's plan is "we'll just sync everything every five minutes," ask them to walk you through what happens at 429.
One more, easy to miss and genuinely disruptive: "US versions of QuickBooks Online support ISO-8859-1 (extended ASCII) character encoding." Customer names with characters outside that set need handling, decided deliberately, not discovered in production.
The Review You Probably Don't Need
This is where a lot of money gets wasted, because the words "QuickBooks app" carry an assumption.
If the integration is for your own company — your portal, writing into your books — you do not need Intuit's App Store review. Intuit's own wording, once an app is set up: "If you want to use your app privately, it's now live and functional."
What you do need before you can get production credentials is Intuit's App Assessment Questionnaire, which gates the production keys — "the Show Credentials switch appears only after the App Assessment Questionnaire is approved." It asks for a EULA URL, a privacy policy URL, your host domain, and launch, disconnect and connect URLs. Intuit estimates "about 30 minutes to complete." It is administration, not a review board, but it does mean you need a privacy policy and a terms page that actually exist.
Listing on the QuickBooks App Store is a completely different undertaking, and only relevant if you intend to sell your integration to other companies. It runs three reviews — technical, security and marketing — with Intuit's own published response times: technical, "the response period is 10 business days once the developer confirms their readiness"; security, "Up to 30 business days from the start of the scan," carried out by "a 3rd-party security review team"; marketing, "5 business days following approval of the security review." Published apps are then reviewed "on an annual basis, or more frequently at Intuit's discretion."
So: a private integration is weeks of build plus about half an hour of forms. A listed app adds months. Make sure your quote is for the one you actually want.
What Should Be Written Into the Quote
Ask for these in writing. They are the difference between an integration that runs for years and one that needs babysitting.
- Which records sync, in which direction, and how often. Customers, items, invoices, payments, credit memos — each named, each with a direction. "Syncs with QuickBooks" is not a scope.
- What is the source of truth for each record. If a price can be edited in both places, one of them has to win, and it has to be decided now rather than discovered during a dispute.
- What happens when QuickBooks is unavailable or throttles. The order should queue and retry, not vanish.
- Where failures surface. A screen somebody actually looks at, and an alert when the connection drops. Silent failure is the normal failure mode here.
- Token maintenance. Something keeps the refresh token alive, and somebody is told before the 100 days run out.
- Sandbox during build, so your live books are never the test environment.
- The Intuit developer account is in your name. Same principle as owning the code: if the app registration belongs to your vendor, you cannot leave.
When Not to Build This
If your volume is low and a person exports a file once a week without complaining, an integration may not pay for itself. If an off-the-shelf connector already covers your exact records and direction, use it.
Build the integration when orders are frequent enough that re-keying them is a real cost, when the re-keying causes errors that reach customers, or when you need the order to exist in accounting the moment it is placed rather than the following Monday. Those are the cases where it repays quickly. Anything else is worth measuring first.
FAQ
Q: Do we need Intuit's approval to connect our own software to QuickBooks Online? A: Not App Store review. A private integration for your own company is, in Intuit's words, "live and functional" once set up. You do have to complete Intuit's App Assessment Questionnaire before production credentials are released — about thirty minutes of forms, but it requires a real EULA URL, privacy policy URL and disconnect URL. App Store listing is a separate process with technical, security and marketing reviews, and is only needed if you intend to sell the integration to others.
Q: Why does a QuickBooks integration stop working after a few months? A: Almost always the 100-day rule. Intuit's refresh tokens expire if unused for 100 days, and when that happens "your app's access to the QuickBooks company terminates. Users will need to sign in and authorize your app again." A system that goes quiet over a slow season disconnects itself. Ask your vendor what keeps the token alive while the system is idle and who gets alerted when the connection drops.
Q: Can a developer test a QuickBooks integration without using our live books? A: Yes, and they should. Intuit gives every developer profile a free sandbox company automatically, up to ten of them, valid for two years. Sandboxes are region-specific and cannot be changed later, so the right country has to be chosen at the start.
Q: How fast can a QuickBooks Online integration sync? A: Intuit allows 500 requests per minute per company and 10 per second, returns a maximum of 1,000 records per query, and recommends no more than 30 payloads per batch. Hitting the ceiling returns HTTP 429 and requires a 60-second wait. That makes a first bulk import of thousands of customers and items a paced operation rather than an instant one, and it is why a good integration batches and backs off rather than retrying blindly.
Read us often? You can add Futurise as a preferred source in your own Google account.