QuickBooks API Integration: Online API, Desktop SDK, Files or ODBC, and Which One to Use

QuickBooks has four ways in, and which ones you have depends on whether you run QuickBooks Online or QuickBooks Desktop. QuickBooks Online has a REST API with JSON and OAuth 2.0. QuickBooks Desktop has no web API: software talks to it in qbXML, through the QuickBooks SDK on the same Windows machine or through the Web Connector from anywhere else. Both also accept file imports (CSV for Online, IIF for Desktop), and a third-party ODBC driver lets reporting tools read them with SQL. Below: the four side by side, how to choose, and a walkthrough of an integration we ran against a live QuickBooks Online sandbox, from OAuth to a created invoice.

---

The four ways in

Online Accounting API

A hosted REST API. You register an app on Intuit's developer portal, the user approves access once on Intuit's consent page, and your software calls https://quickbooks.api.intuit.com/v3/company/{realmId}/... with a bearer token. It has a SQL-like query language, full create, read, update and delete on customers, items, invoices, bills, payments and the rest, and reports. This is the one to build on if you run QuickBooks Online.

SDK and Web Connector

QuickBooks Desktop exposes its data through a request processor on the Windows machine where it runs, speaking qbXML. Software on the same machine calls it directly. Anything else goes through the QuickBooks Web Connector, a small program that polls your web service on a schedule and carries qbXML messages back and forth. It works, it is old (the programmer's guide is version 2.0), and it depends on that PC being on with QuickBooks able to open the file. We explain the loop, the callbacks and the XML in QuickBooks Web Connector and qbXML, explained.

File import

QuickBooks Online imports customers, vendors, products and services, and some transactions, including invoices, from CSV or Excel. QuickBooks Desktop imports IIF, Intuit's tab-delimited interchange format. IIF is fast for a one-off load, but it skips many of the checks QuickBooks applies to data entered by hand. Back up the company file before every IIF import, and never use it for ongoing sync.

ODBC

Third-party ODBC drivers such as QODBC present QuickBooks data as SQL tables, so Excel, Power BI or any SQL tool can read it. It is a reporting route, not an integration one: writing through it is possible but you inherit every limitation of the layer underneath.

Which one to use

• You run QuickBooks Online: the Online API, for anything that has to stay in sync. CSV import for a one-off load.
• You run QuickBooks Desktop and the integration is web software: the Web Connector, accepting that sync runs every few minutes, not instantly.
• You run QuickBooks Desktop and only need reports: ODBC.
• You are moving from Desktop to Online: build on the Online API now, and read what Intuit is ending on Desktop first.

A walkthrough on a live sandbox

To write this, we built a small bridge (open source on GitHub) and ran it against a QuickBooks Online sandbox company, Intuit's sample landscaping business with customers like Cool Cars and items like Rock Fountain. It exposes QuickBooks to AI assistants as MCP tools, which we cover in QuickBooks MCP. Here is what the API part involved.

1. OAuth 2.0

Register an app on developer.intuit.com with the com.intuit.quickbooks.accounting scope, then send the user to Intuit's consent page:

https://appcenter.intuit.com/connect/oauth2
  ?client_id=...&response_type=code
  &scope=com.intuit.quickbooks.accounting
  &redirect_uri=http://localhost:8765/callback
  &state=<random>

Intuit redirects back with a code and the company's realmId. Exchange the code at https://oauth.platform.intuit.com/oauth2/v1/tokens/bearer, with your client ID and secret as HTTP basic auth. You get an access token that lasts one hour and a refresh token.

Our first attempt failed with "The redirect_uri query parameter value is invalid." The URI has to be added to the app's Development keys, exactly as sent, and saved. A sandbox app accepts http://localhost; a production app needs a public HTTPS callback.

Refresh tokens rotate. Every refresh returns a new refresh token, and the old one stops working. Save the new one every time, or the integration silently loses access weeks later.

2. Reading with the query language

Searches go through one endpoint with a SQL-like language, and every call should pin a minorversion so the response shape doesn't change under you (we use 75; Intuit has been retiring older ones):

GET /v3/company/{realmId}/query
  ?query=select * from Item where Active = true and Name like '%sprinkler%'
  &minorversion=75

On the sandbox, that returned two items, Sprinkler Heads ($2) and Sprinkler Pipes ($4). Remember that answer: it matters in the next step.

3. Writing an invoice

An invoice references the customer and each item by QuickBooks ID:

{
  "CustomerRef": { "value": "3" },
  "Line": [
    { "Amount": 550, "DetailType": "SalesItemLineDetail",
      "SalesItemLineDetail": { "ItemRef": { "value": "5" }, "Qty": 2, "UnitPrice": 275 } },
    { "Amount": 60, "DetailType": "SalesItemLineDetail",
      "SalesItemLineDetail": { "ItemRef": { "value": "16" }, "Qty": 30, "UnitPrice": 2 } },
    { "Amount": 150, "DetailType": "SalesItemLineDetail",
      "SalesItemLineDetail": { "ItemRef": { "value": "7" }, "Qty": 3, "UnitPrice": 50 } }
  ]
}

POST /v3/company/{realmId}/invoice?minorversion=75 created invoice 1038 for Cool Cars: $760, dated that day and due 30 days later.

4. The part the API doesn't do for you

The order behind that invoice said "2 fountains, 30 sprinklers, 3 hours install". The API needs IDs, so something has to turn "sprinklers" into item 16. Taking the first search result could have invoiced the wrong product: "sprinkler" matches both heads and pipes. So our bridge never guesses. It drafts the invoice, lists what it could not resolve ("sprinkler" matches 2 items: which one?), and writes nothing until a person has answered and approved the total. That rule, more than the API calls, is what makes an integration safe to leave running.

Two smaller lessons:

• Keep the intuit_tid response header in your logs. It identifies the call when you need Intuit's support.
• Read the error body. Intuit's errors carry the useful part in Fault.Error[].Detail, not in the HTTP status.

What it costs

The API calls are the small part. The work is in matching your data to QuickBooks', handling what can't be matched, and deciding who approves what. Our published prices: scoping one workflow costs $2,300 to $4,700, and a first workflow in production starts at $17,500, then from about $470 a month to run it. A data migration or a simpler sync is quoted as a first slice of custom software, from $5,000.

Related: QuickBooks Web Connector and qbXML, QuickBooks MCP, and QuickBooks automation with AI.