Integrations rarely break on the happy path. They break on a bad night.
An integration that moves jobs, invoices, and payments between Jobber and QuickBooks usually works in the demo. What breaks it are five things that rarely happen while anyone is watching: QuickBooks loses the answer to a write, an API throttles you, a token expires halfway through a sync, a webhook arrives twice, or the two systems disagree about who a customer is. Each one can leave a duplicate invoice, a missing payment, or a second copy of a customer in a business's books.
This week I released fieldtwin, an open-source tool that makes all five happen on demand. It runs twins of the Jobber and QuickBooks Online APIs on a laptop, with a fake trades business in both, so integrations and AI agents can be tested without touching a real customer's account. Below is each failure, what it does in production, and how to test for it. If you own the business rather than write the code, skip to the four questions to ask before anyone connects to your books.
A write that worked, and an error that says it didn't
Your code sends QuickBooks a new invoice. QuickBooks creates it, but the answer never makes it back: a gateway times out, or the connection drops. Your code sees an error and tries again, and QuickBooks creates a second invoice for the same work.
QuickBooks has a guard for this: a requestid sent with each write. Send the same one again and QuickBooks returns the first answer instead of writing twice (Intuit's docs). Code that doesn't send one books the work twice every time an answer is lost, and nobody notices until the customer is billed twice or the bookkeeper finds it at month end.
fieldtwin can lose answers on purpose. A fault rule with lostResponse does the write, then answers with a 504 anyway, the way a gateway timeout hides a write that succeeded. The README has a test that loads the flaky-apis scenario, runs your sync, and fails if any invoice was booked twice.
Two APIs, two ways of saying slow down
QuickBooks allows 500 requests a minute for each company and answers HTTP 429 past that. Jobber prices every GraphQL query against a budget of 10,000 points that refills at 500 a second, and answers THROTTLED when a query costs more than is left. A sync that works on ten test invoices can stall on a busy Monday.
Code has to back off and try again, and it has to keep each Jobber query small enough to ever run: one that asks for more than the whole 10,000-point budget is refused every time, however long you wait. fieldtwin enforces both limits, and its heat-wave-monday scenario adds throttled QuickBooks writes and a slow Jobber to a busy HVAC Monday with 120 customers.
A token that expires halfway through the sync
Both vendors use OAuth 2.0, and their access tokens last 60 minutes. Jobber also rotates refresh tokens: each refresh hands back a new one and the old one stops working, so two processes that refresh at once can lock each other out. QuickBooks keeps a refresh token alive on a rolling 100 days.
Testing this honestly means waiting an hour, so it rarely gets tested. In fieldtwin, tokens expire on twin time, a clock you move forward with one request, so a test of your refresh path takes a second. The reference integration in the repository gets through two hours of token expiry, and more than a hundred retries, in a couple of seconds.
The same news twice, or out of order
Jobber's docs say the same webhook “may be delivered more than once”. Intuit's say events can arrive “out of sequence”. So news of a payment can come twice, or after the update that followed it, and code that acts on each message as it arrives records a payment twice or undoes a newer change.
fieldtwin sends webhooks the way each vendor does, signed so your verification code runs unchanged, and retried when your app doesn't answer in time. Fault rules can send any of them twice, or late enough that later ones overtake them.
Two systems, two versions of the same customer
In a real business, Jobber and QuickBooks drift apart. The office types a name one way in Jobber and the bookkeeper types it another way in QuickBooks. Some customers exist in only one system. A bookkeeper marks a customer inactive in QuickBooks, and months later the customer calls again: a sync that looks for active customers won't find them, and creates a duplicate.
Add someone editing a customer in QuickBooks while your sync is updating it, which QuickBooks refuses as a stale change, and matching customers becomes the hardest part of the job. fieldtwin's mismatched-books scenario builds all of this into the fake business on purpose, so you can see whether your code, or your AI agent, notices.
Judge an agent on what it changed, not on what it says
An AI agent that works in Jobber and QuickBooks needs somewhere to make its mistakes, many times over. In fieldtwin you mark a checkpoint, let the agent work, and get back the exact list of what it changed in each system, one line per change. Then rewind, and run it again from the same starting point.
That list is the test. An agent can report that it reconciled the books; the change list shows whether it created three duplicate customers along the way. fieldtwin also has an MCP server, so a coding agent like Claude Code can drive the test world itself, and a dashboard that shows both systems side by side with every drifted record marked.
A twin, not the real thing
fieldtwin is modeled from Jobber's and Intuit's public developer docs. It is not the real APIs, and it doesn't pretend to be. Every behavior is listed in the project's FIDELITY.md, with how closely it matches and the docs page it came from. Where the docs are silent, it takes the cautious reading and says so.
It doesn't replace the vendors' sandboxes either, and a final check there before going live is still worth doing. What it adds is what a sandbox can't give you: a realistic business in both systems at once, failures on demand, time you can skip, and an undo. It's free and open source under the Apache 2.0 license, and independent: it isn't affiliated with or endorsed by Jobber or Intuit.
Four questions before anyone connects to your books
You don't need to read code to protect your books. Ask whoever is building your integration or AI agent these four questions, and listen for specific answers.
- 01What happens if QuickBooks times out while it's creating an invoice? Listen for a request ID, or another way it never writes the same thing twice.
- 02Where did you test it? Not on your live account: a twin or a sandbox, with failures switched on.
- 03Can you show me exactly what it changed? A list, not a summary, and a way to undo it while testing.
- 04What does it do when Jobber and QuickBooks disagree about a customer? Listen for how it matches people, and what it does when it isn't sure.
A clear answer to all four is worth more than any demo.
No developer account, no test data to type in
fieldtwin needs Node 22 or newer. Clone the repository, run npm ci and then npm start, and point your code at http://localhost:4010 instead of the vendors' addresses. The fieldtwin page has two short demo videos.
The repository also has a reference Jobber-to-QuickBooks integration you're welcome to copy, and the roadmap: more vendors, such as Housecall Pro, are next. If you've worked with either API and the real thing surprised you, open an issue. That's how the twin gets more faithful.