QuickBooks Integration · updated 2026-08-22

Architecture and reliability: how the sync engine works under the hood

For the technically curious: the engineering that makes the integration dependable enough for your ledger. This is the same infrastructure pattern that powers our public API webhooks.

1. 1

   Outbox queue, never inline

   Nothing in your operation ever waits for QuickBooks. When an invoice, customer, payment or refund changes, a database trigger writes an event to a durable queue in the same transaction. A worker picks events up within about two minutes and delivers them to QuickBooks. If Intuit is slow or down, your dispatch board, booking page and payments continue exactly as always.

2. 2

   Retries with backoff, and a hard stop

   Transient failures (network, QuickBooks 5xx, rate limiting) retry automatically at increasing intervals: 1, 5, 30 and 120 minutes, up to 5 attempts. Definitive business rejections (for example, a validation error from QuickBooks) do not retry blindly; they surface in the sync log with the exact reason. Authorization failures pause the connection immediately and never hammer Intuit with a dead token.

3. 3

   Deduplication and ordering

   The queue keeps at most one pending event per entity, so a burst of edits becomes one sync. Ordering is resolved at delivery time: an invoice sync first guarantees its customer exists in QuickBooks; a payment sync first guarantees its invoice. Dependencies are never delivered out of order, even when queue items retry at different times.

4. 4

   Crash safety: the reaper

   If a worker dies mid-delivery, the claimed item would be stuck. A reaper returns any item stuck in processing for more than 15 minutes back to the queue. Handlers are idempotent (they check the entity map before creating), so a re-delivery after a crash updates instead of duplicating.

5. 5

   Token refresh, engineered against races

   QuickBooks access tokens expire hourly and refresh tokens rotate. The integration refreshes proactively with a two-minute margin, stores rotated tokens atomically with a compare-and-set (two concurrent refreshes can never corrupt the connection), and if a refresh loses a race it adopts the winner's token instead of erroring. A genuinely dead refresh token (revoked, expired after ~100 days of inactivity) marks the connection as needing reconnection, visibly.

6. 6

   Recovery after reconnection

   Items that failed while a connection was broken are replayed automatically when you reconnect, newest state first, without duplicating anything. If you reconnect a DIFFERENT QuickBooks company, the integration clears its entity map so records are never written into the wrong ledger.

7. 7

   Observability: intuit_tid everywhere

   Every failed call to Intuit logs the intuit_tid response header, Intuit's own transaction id, and shows it in the sync log. If you ever open a case with Intuit support, that id lets them find the exact request. Nothing fails silently is not a slogan; it is the design invariant of this integration.