Accounting API Sync4 providers · one trait · zero drift

The client sold an accounting add-on to small businesses. Their existing integration layer polled each provider every fifteen minutes, diffed blobs of JSON, and hoped for the best. It was a constant source of “why is this invoice wrong?” tickets and a meaningful fraction of their AWS bill was wasted polling customers who hadn't changed anything.

They wanted webhook-driven, bidirectional, and reliable. They wanted the integration layer to stop being a source of support load.

• Four providers with radically different APIs: OAuth flavors, rate limits, entity models, webhook support (or lack of it).
• Bidirectional sync. Changes originate in either the app or the accounting tool; both must converge.
• Conflict resolution had to be explicit, not last-write-wins. Finance teams do not forgive silent overwrites.
• No user-visible sync delay for common flows — edit an invoice, see it reflected within 30 seconds.
• Backfills had to be resumable. A 2-year import cannot redo itself on a dropped connection.

One Go trait (“provider”) with a stable entity vocabulary (invoice, bill, account, contact, etc.), four implementations behind it. Each provider adapter owns its OAuth, rate limiting, and webhook parsing; the rest of the system doesn't know or care which provider is on the other side.

Temporal runs every sync as a workflow. A change event — from a webhook, a user edit, or a scheduled reconciliation — triggers a workflow that: fetches the current state from both sides, compares, applies the conflict policy, writes the resolution, and emits an audit event. Retries, timeouts, and compensations live in the workflow definition, not the business logic.

The conflict policy is configurable per entity and per customer. “Invoices: app wins.” “Contacts: accounting tool wins.” “Tax rates: always raise a conflict for human review.” The default is raise-for-review, not silent resolution.

• Wave doesn't have webhooks. AccountEdge has them for half the entities. We ended up with a hybrid model: webhooks where available, targeted polling where not, with polling intervals scaled by historical write rate per customer.
• OAuth token rotation. Three providers rotate differently, one rotates silently during normal API calls. Token refresh had to be centralized and paranoid.
• Idempotency. A retried webhook must not create a duplicate invoice. Provider-native idempotency keys, where supported, plus our own event-hash layer underneath.

In production for over two years. Handles eighteen entity types across four providers with a median edit-to-reflect latency under 30 seconds. Zero drift incidents since GA. AWS spend on the sync layer is roughly a third of the old polling architecture because the workflow engine only runs when there's actual work to do.

I'd model the entity schema as a versioned contract from the first commit. We shipped v1 without one, which made it painful to add QuickBooks' class-tracking fields in month eight without touching every call site. Versioned schemas from day one are a small amount of ceremony you thank yourself for later.