Quickstart

TenkeyBridge exposes QuickBooks Desktop (and Enterprise) through the same REST shape as the QuickBooks Online Accounting API. If you already have a working QBO integration, you don't rewrite it — you point it at TenkeyBridge.

You can make your first call in a few minutes, before you connect any QuickBooks: every organization comes with a sandbox.

1. Sign up and find your sandbox

Sign up (or sign in if you already have an account) and create an organization. Open Realms: your sandbox (for example ExampleCo Sandbox) is already there, with a sandbox badge. Copy its realm id.

2. Create an OAuth client

Under OAuth clients, choose New client and enter your app's redirect URI (a localhost URI is fine for development). Copy the client id and secret; the secret is shown once.

3. Authorize and call

Run the standard OAuth 2.0 code flow (see Authentication) with the sandbox's realm id as realm_id on the authorize URL. Then call the API exactly as you would QBO:

curl "https://api.tenkeybridge.com/v3/company/$REALM_ID/query?query=select%20*%20from%20Customer%20MAXRESULTS%205" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Accept: application/json"

You get ExampleCo's customers back in QBO's QueryResponse shape.

The only required change

Same OAuth 2.0 flow, same paths, same JSON entities. Swap the base URL:

- const BASE = "https://quickbooks.api.intuit.com";
+ const BASE = "https://api.tenkeybridge.com";

Everything else stays:

// Unchanged from your existing QBO code
const res = await fetch(
  `${BASE}/v3/company/${realmId}/invoice/${id}`,
  { headers: { Authorization: `Bearer ${accessToken}` } }
);
const invoice = await res.json();

4. Connect your QuickBooks

When your integration works against the sandbox, create a regular realm in the portal and connect a QuickBooks company file in four steps with the Web Connector — nothing to install. Authorize your app against that realm the same way; only the realm_id changes.

What to expect

Reads come back essentially unchanged — the compatibility matrix marks almost every entity's read side Full. Writes are where Desktop's quirks surface: line-item shapes, tax handling, and a handful of fields need a quick, documented change before they behave identically to QBO. The sandbox applies the same rules, so you meet them while building.

Updates work the way you'd expect from QBO: POST the entity with Id and SyncToken, optionally with ?operation=update on the URL (both are accepted, and a body with Id is always routed as an update — it never falls through to create). One semantic difference to know: Desktop has no partial-update mode, so every update behaves like QBO's sparse update — fields you omit from the body are left alone, never cleared, even on a full-body update with no sparse flag set.

When you hit a case Desktop genuinely can't do, you get a QBO-style Fault back with a stable, versioned error code instead of a silent difference — see Error codes for the full list and what to do about each one.

Before you integrate a new entity, check the entity matrix for its field-by-field support, its Sandbox column, and the exact fix for anything marked partial. Cross-cutting rules for IDs, SyncToken, sparse updates, and query support live in IDs, SyncToken & sparse updates.

Where to go next

1. Sandbox — sample company, fixed ids, reset, limits.
2. Testing your integration — sandbox, Intuit sandbox, real company file.
3. Authentication — OAuth 2.0 code flow (same as QBO).
4. Node.js client — @tenkeybridge/client, typed helpers + token management for new code.
5. Connect QuickBooks — open one .qwc file in QuickBooks' built-in Web Connector; nothing to install.
6. Entity matrix — full live / planned / gap coverage.