Workflow People beta
Sign In
← Back to blog
May 2026

Why I'm not building a QuickBooks connector

Every accountant who tries Workflow People asks the same question in the first five minutes:

"Does it connect to QuickBooks?"

The honest answer is "no, on purpose." Let me explain why I think that's a feature, not a missing one.

The connector treadmill

Every workflow tool starts with one or two integrations and then never stops. Zapier, Make, n8n, Stack AI — they advertise their integration count like a points score. 100 connectors. 500 connectors. 1,000.

Each connector is a piece of code that has to be maintained forever. The vendor changes their API; the connector breaks. The vendor changes their auth model; the connector breaks again. New API versions ship while old ones get deprecated. It is one of the worst maintenance treadmills in software, and the tool gets less reliable over time, not more. Anyone who's used a connector-based platform for three years has war stories.

I'm one person. I can't run that treadmill, and I wouldn't want to even if I could.

What an LLM changes

Here's what the platforms-with-100-connectors haven't fully internalized: a modern LLM can read an API documentation page and generate the right code to call that API. Both directions — send and receive.

Modern open systems use secret API keys. You log into your accounting platform, your CRM, your billing system, and generate a key. That key authenticates every request. Almost every business tool built in the last decade works this way.

If the LLM can write the request and the user can provide the key, you don't need a connector. You need a place for the key to live and a way for the AI to know what the API can do.

What this looks like in the app

Three things, no special UI per integration.

1. Settings → Connections

A simple panel that stores name + encrypted value pairs. You add one for each API you use: 

quickbooks   = sk_live_abc123...
supabase     = eyJhbGc...
sendgrid     = SG.xyz123...

The values are encrypted. They never appear in any prompt sent to the LLM. They're only available to tool code at runtime, through api.getSecret("quickbooks").

2. A knowledge pack that teaches the AI about the API

You don't have to write the integration. You write what the API does. Endpoints, auth pattern, response shapes. The AI reads the pack when building a workflow and generates the right calls. 

/kb-build quickbooks-api

"QuickBooks Online API at quickbooks.api.intuit.com/v3.
Auth: Bearer token in header. Common endpoints:
- /company/{realmId}/reports/TrialBalance — returns TB as JSON
- /company/{realmId}/query?query=... — SQL-like queries
- /company/{realmId}/invoice — list/create invoices.
Use api.getSecret('quickbooks') for the token."

That knowledge pack ships inside your .wfp file. If you share the workspace with a colleague, the API description goes with it — they just need to add their own QuickBooks key to their own Settings.

3. The AI writes the integration as a custom tool

When you describe a workflow, the AI reads the knowledge pack and generates a tool like: 

const token = await api.getSecret("quickbooks");
const r = await api.fetch(`https://quickbooks.api.intuit.com/v3/company/${realmId}/reports/TrialBalance`, {
  headers: { Authorization: `Bearer ${token}` }
});
return await r.json();

You see the code in the plan. You approve. The tool runs as part of your workflow. The integration is now a step in your .wfp file — yours to edit, yours to keep, yours to share.

Three modes, depending on how much integration you want

1. Just paste a CSV. Most people, most of the time. QuickBooks exports CSV. Sage exports CSV. Xero, NetSuite, your bank — all CSV. The "paste an export" path is the universal connector. No keys, no API knowledge pack, no code.

2. Ad-hoc API call. One-time analysis that needs live data. Add the key to Connections, paste the API doc into knowledge, ask the AI to fetch. The credential lives encrypted in your workspace; the data flows back into your session.

3. Reusable workflow step. Same data pulled the same way every month? Save the integration as a workflow step. "Pull QBO trial balance" becomes a deterministic piece of your monthly close — and you own it, not me.

Yes, this is more work the first time

The trade-off is honest. With Workflow People, a one-time API integration takes ten minutes of your time the first time. With a tool that has a pre-built QBO connector, it takes thirty seconds.

You get three things in return:

  • You own the integration. It's a workflow step in your .wfp file. It doesn't depend on me. If I disappear, the integration still works — anywhere the .wfp runs, including inside Claude or ChatGPT directly.
  • It can do anything the API can do. Pre-built connectors expose a curated subset of operations. The LLM-generated approach uses the whole API surface.
  • You're not waiting for me. Need a Xero-specific report that isn't in any commercial connector? Write a knowledge pack, ask the AI. Done.

Where this falls down

Two cases where a pre-built connector still wins:

  • OAuth flows that aren't friendly to copy-paste. Some APIs (Google's, Microsoft's) require browser-based auth handshakes that don't fit the "paste your API key" model. For these, you may need to handle auth outside the app and paste the resulting token in.
  • High-frequency polling. If you need a workflow that hits an API every five minutes, the LLM-generated approach isn't the right tool. That's an n8n use case.

For everything else — month-end pulls, weekly snapshots, ad-hoc data fetches — the LLM-plus-API-docs path is faster than waiting for me to build connectors.

Where this could go

I'm not closing the door on integrations forever. But if I add them, they'll be user-contributed knowledge packs — .wfp snippets that someone in the community wrote and shared, that you can drop into your workspace. A community-maintained "QuickBooks API pack." A "Stripe API pack." A "Plaid API pack." Not vendor-maintained connectors I have to keep working.

This is the same reason the .wfp format is open source. The integrations belong to the people who use them, not the platform that hosts them.