Integration guides
What are API integrations? A plain-English guide for business owners
Flow Mesh · · 6 min read
Sooner or later a vendor, a consultant or your IT provider tells you two of your tools "can be connected through the API". It sounds technical, and the quote that follows can be hard to judge if you do not know what is being built.
The short answer: an API (application programming interface) is a published set of instructions that lets one piece of software ask another for data, or ask it to do something. An API integration is any connection that uses those instructions to move data between your tools automatically. Native connectors, Zapier and Make, and custom code all use APIs underneath; they differ in who builds and maintains the connection.
An API in one paragraph
Think of an API as a service counter with a printed menu. Your CRM's API might list items such as "give me the contacts changed since yesterday" or "create a new company with these details". Another program walks up, shows its credentials, orders from the menu in the exact format required, and gets a structured answer back. It cannot order anything that is not on the menu, and it can only see what its credentials allow.
That last point is why API integrations are usually safer and more reliable than the alternatives, such as exporting spreadsheets or a robot clicking through screens: the vendor decides what is exposed, and every request is authenticated.
The parts you will hear about
Endpoints
Each menu item is an endpoint: one address for contacts, another for invoices, another for payments. When someone says "the API does not support that", they usually mean there is no endpoint for it. Check this early. A tool may have an API that covers clients and invoices but not documents or time entries.
Authentication: keys and OAuth
Software proves who it is in one of two common ways:
- API keys: a long secret string generated in the tool's settings. Simple, but anyone holding the key has its access, so it must be stored securely and rotated when people leave.
- OAuth: the "Sign in with..." screen where you approve access for an app. The app receives a token rather than your password, and you can revoke it from the tool's settings.
Who generated the key, or whose login approved the OAuth screen, matters more than it seems. If it was an employee's personal account, the integration can stop the day that account is closed.
Rate limits
Every API caps how often you can call it. These limits are published and can change, and they are often tied to your plan. Two examples, as listed in October 2026:
- Xero's API limits allow 60 calls a minute per connected organization, 5 at once, and 5,000 a day on paid developer tiers or 1,000 a day on the free Starter tier.
- HubSpot's usage guidelines allow private apps 100 requests per 10 seconds on Free and Starter accounts and 190 on Professional, with a separate daily limit shared across the account.
For a small firm syncing a few hundred records a day, these limits rarely bite. They matter during a first import of thousands of historical records, or when a poorly built integration re-checks everything every few minutes.
Webhooks versus polling
There are two ways to notice that something changed:
- Polling: the integration asks "anything new?" on a schedule, every few minutes or every half hour. Simple, but it introduces delay and uses up rate limits.
- Webhooks: the tool sends a message the moment something happens, such as an invoice being paid. Faster and lighter, but only available for the events the vendor chose to support.
This is why one connector feels instant and another lags by 30 minutes. Neither is broken; they are built differently.
Plan gating
API access is often a paid feature. Karbon's API terms of use restrict access to its Business and Enterprise tiers, and Xero moved to tiered developer pricing in March 2026. Before anyone quotes a custom integration, confirm that your current plan on each tool includes the API access the design needs.
Three ways to use an API
| Who builds it | Who maintains it | Best for | |
|---|---|---|---|
| Native integration | The vendor | The vendor | Common syncs between two named products |
| Automation platform (Zapier, Make, n8n) | You or a consultant, visually | You, on the platform's connectors | Workflows across several tools, missing steps |
| Custom code | A developer | Whoever owns the code | High volume, unusual logic, no connector |
Our article on native integration vs Zapier vs custom API goes through how to choose between them.
What can go wrong
API integrations fail in predictable ways, and most of them have nothing to do with code quality:
- Expired or revoked credentials. A password change, a departed employee or a security review breaks the connection quietly.
- Changed fields. Someone renames a custom field or a pipeline stage, and the integration writes to the wrong place or stops.
- Duplicates. Two integrations both create the same client, or a retry runs twice. Our guide to syncing data without duplicates covers the matching rules that prevent this.
- Vendor changes. APIs are versioned and old versions are retired. Pricing and limits change too, as Xero's 2026 change showed.
- Nobody watching. An integration with no error alerts can fail for weeks before anyone notices missing invoices.
Questions to ask before paying for an API integration
- What exactly will move, in which direction, and how often? You should get a one-sentence description per flow.
- Which tool is the source of truth for each record?
- Is there a native integration that already does most of this? If so, why not use it?
- Do our current plans include the API access needed, and do any limits apply at our volume?
- Whose account will the connection run under? It should be a firm-owned admin or service account.
- Where does the code or workflow live, and who can see the logs?
- What happens when it fails? Who is alerted, and how fast?
- What will maintenance cost each year, and what does it cover?
A good answer to all eight fits on two pages. If it does not, the scope is not clear yet.
How Flow Mesh helps
Our stack audit checks what each of your tools can actually expose, gives every tool a verdict (keep, configure, consolidate or replace) and writes up which connections should be native, platform-based or custom. If you go ahead, integration work is scoped and quoted in writing after the audit and built inside your own accounts.
Key takeaways
- An API is a vendor's published menu of what other software may read or change; an API integration uses it to move data automatically.
- Native connectors, Zapier and Make, and custom code all run on APIs; the difference is who builds and maintains them.
- Check endpoints, authentication, rate limits, webhooks and plan gating before anyone quotes a build.
- Most failures come from expired credentials, renamed fields, duplicates and nobody watching the errors.
- Run every connection under a firm-owned account and give it a named owner.