WebsitesBy Xavier Peich

Getting your software to talk to each other: what an API integration fixes, and what it doesn't

An API is a door one program opens to another. Native connector, Zapier or custom build: how to choose, and what breaks once the integration is live.

Getting your software to talk to each other: what an API integration fixes, and what it doesn't

In plenty of small businesses, a new client exists three times. Someone enters them in the CRM after the first call, types them again into the invoicing tool when the contract is signed, then a third time into the calendar for the first meeting. It takes a few minutes and nobody complains. Yet connecting those tools is one of the most profitable jobs a small business can hand to a custom software developer, or to nobody at all, when the link already exists.

It is also the job whose aftermath gets sold the worst. An integration is a small piece of software that depends on two vendors, and neither of them asks you before changing the rules. Below: what an API is in owner terms, three ways to connect two programs, and what breaks once everything works.

The short answer, for the busy

An API integration connects two programs so that data entered in one shows up in the other without anyone retyping it. An API is a door a software vendor publishes for other programs, with posted rules: who may come in, how many times per minute, and which data gets through. A small business has three options. If a native connector exists between its two tools, it switches it on. If the flow is simple and linear, a glue tool such as Zapier or Make is enough. A custom integration is justified when volume, business rules or a system with no connector go beyond those options. In all three cases, the real cost arrives after go-live: access tokens that expire, API versions that get retired, call limits, vendors changing their terms, and syncs that fail silently. An integration with no owner and no alerts will eventually let your systems drift apart.

The real cost of double entry

The minutes spent retyping are visible. The cost that matters isn't: three copies of the same client are three versions of the truth. When the client moves, the address changes in the CRM because that's where they called. The invoicing tool keeps the old one, and the next invoice goes to the wrong place. Nobody made a mistake; the setup manufactured one.

Double entry also creates a quiet dependency. Often only one person knows which program is authoritative for which piece of data. When that person goes on vacation, the knowledge goes too.

We won't give you a figure for hours saved. It depends on your volume, and the published figures come from companies selling integration tools. Do the math yourself: how many records a week, copied how many times, and how many errors per quarter come from a copy that didn't keep up? The point of an integration is a single source for each piece of data, with every other program reading it instead of copying it. The time saved is a bonus.

An API, without the jargon

API stands for application programming interface. In owner terms, it's a door a software vendor opens to other programs. It is published and documented, and the vendor posts three rules on it.

Who may knock. The account holder consents once, and the program receives a token, a kind of temporary pass the door checks on every call. No valid token, no entry.

How often. Every door has a maximum rate. For QuickBooks Online, Intuit sets the limit at 500 requests per minute per company, and 10 per second per company and app. Beyond that, the door answers with error 429, "too many requests," and Intuit asks you to wait 60 seconds before retrying.

What gets through. The vendor decides which data it exposes, for reading and for writing. What it doesn't expose can't be integrated, whatever your budget.

The practical consequence: an integration will never be better than the door. Before asking "can we connect X and Y?", ask what X's and Y's APIs let through. And when you shop for software, open its pricing page before signing: if API access appears only in the top tier, or not at all, the integration just changed price.

Three cases, from cheapest to most expensive

A native connector exists: switch it on. Often both vendors have already built the link. Look in each tool's settings for an Integrations, Apps or Marketplace page. Turn it on, map the fields, test with a single record. It's the cheapest option, and often the right one. Its limit: the connector syncs what the vendor chose, in the direction the vendor chose, and you can't add your own rule. Also check who maintains it: the vendor itself, or a third party listed in its app store.

A glue tool is enough. Zapier, Make or, in the Microsoft world, Power Automate go through the same doors: a trigger, then steps. For a linear flow at modest volume, with someone in-house to look after it, that's the right tool. We've covered where the limit sits in our no-code versus custom comparison and in the Power Automate article.

You need a custom integration. Three signals. Volume first: importing years of history runs into the limits, and QuickBooks Online returns at most 1,000 records per query, so the job has to page through results and pace itself. Rules next: does this client already exist under another name? Which system wins when two records disagree? Last, the program that has an API but no connector, which describes a lot of industry-specific software. This is the "thin layer" described in our custom software or SaaS article: keep your subscriptions and build only what connects them, sometimes all the way to a portal where clients check their own file.

At Peich, we build this kind of integration: the article on AI agents in accounting describes one, our connector between QuickBooks and AI assistants. Those assistants knock on the same doors, through the MCP protocol.

Software with no API at all is the hard case: automate a file export, or replace the software.

What breaks over time

On go-live day, an integration works. Its failures arrive months later, and they almost always come from outside.

Tokens expire. For QuickBooks Online, the access token lasts only an hour, and the token used to renew it changes regularly: as soon as Intuit hands out a new one, the old one stops working, so the integration must always keep the latest. At Squarespace, the refresh token expires after seven days and works only once. At Google, an app left in "Testing" status gets refresh tokens that expire after seven days. At Microsoft, the client secret of an app registered in Entra can't last more than 24 months, and Microsoft recommends under 12. The integration then stops on an anniversary nobody wrote down.

Versions get retired. Shopify ships a new API version every quarter and supports each one for at least 12 months before retiring it. An app that calls a retired version gets no error: Shopify answers with the oldest version still accessible. Nothing crashes. The responses change shape, which is often worse.

The vendor changes its terms. In May 2025, Intuit announced a partner program, launched July 28, 2025 in the US, on a separate timeline for other countries. It sorts calls to its accounting API into two categories. Writing to QuickBooks, creating an invoice or a customer, stays free and unmetered. Reading (accounts, reports, queries) is now counted: the free tier includes 500,000 such calls a month per workspace, and beyond that, calls are refused. For a small business's integration, that ceiling is far away. The lesson is bigger than the number: the vendor holds the door, and it made data coming in free and data going out metered.

The sync fails silently. Many integrations receive automatic notices, webhooks, when something changes at the vendor. If your server doesn't answer, Shopify retries up to eight times over four hours, then removes the subscription. Stripe retries for up to three days. After that, nothing arrives, and no software tells you the numbers have stopped matching. You find out at month-end, when the sales report and the books no longer agree.

What a well-built integration plans from day one

None of these failures can be prevented for good. What you choose is when you find out: the same day, or at month-end. A well-built integration ships with six pieces.

A named owner. One person knows the integration exists, what it syncs, and whom to call when it stops.

Access in the company's name. The app registered with the vendor and its tokens belong to a company account, not to the employee who set it up. Known expiry dates go in a calendar.

An alert on the first failure. An error log nobody reads is useless. A human should get an email or a message at the first failure, not after the eighth.

A reconciliation check. Once a week, the integration compares its two sides itself: number of clients, total invoiced this month. A gap triggers an alert before your accountant finds it.

A pinned version and someone watching. The integration calls a specific API version, and someone subscribes to the vendor's changelog, as Shopify recommends.

One rule of truth per field. The address comes from the CRM, the balance from the accounting system, and it's written down somewhere.

Where to start

List the data your team types more than once, and the programs it travels between. For each pair, look for a native connector first, then a glue tool. Consider custom work only after that, and ask whoever proposes it how they'll handle tokens, versions and alerts. If they have no answer, they're selling you the easy part.

It's a conversation we have often: which pairs to connect, with what tool, and who looks after it afterwards. We'll also tell you when a connector you already pay for does the job.

→ Let's talk about the software your team retypes

Xavier PeichWritten byXavier Peich