Most businesses do not have a software problem. They have a joining-up problem. The CRM knows one thing, the accounting system knows another, the warehouse knows a third, and a human spends their week copying between them. API integration is the work of making those systems talk directly.
An API (application programming interface) is a defined way for one piece of software to ask another for data or to tell it to do something. API integration is the process of connecting two or more systems through those interfaces so information moves automatically. The API is the socket; the integration is the wiring you build to plug into it.
How an API call actually works
Strip away the jargon and a typical API call has five steps:
- Request. Your system sends a message to a specific URL — an endpoint — saying what it wants (
GET /customers/482) or what it wants done (POST /invoices). - Authentication. The request carries proof of identity: an API key, an OAuth token, or a signed credential. Without it the other system refuses to answer.
- Processing. The receiving system validates the request, checks permissions, and does the work.
- Response. It sends back structured data — almost always JSON — plus a status code.
200means success,401means your credentials failed,429means you are being rate-limited,500means something broke on their end. - Handling. Your system reads the response, maps the fields into your own data model, and decides what to do if the answer was an error.
That last step is where integrations are won or lost. Sending a request is easy. Deciding what happens when the response never arrives is the actual engineering.
The four integration patterns
Nearly every integration you will ever commission is one of these four shapes. Knowing which one you need makes conversations with developers far more productive.
| Pattern | How it works | Best for |
|---|---|---|
| Polling | Your system asks “anything new?” on a schedule | Systems with no webhook support; tolerable delay |
| Webhooks | The other system pushes an event to you the moment it happens | Real-time reactions — new order, payment received |
| Batch / scheduled sync | Bulk transfer on a timer, often overnight | Reporting, reconciliation, large data volumes |
| Direct request/response | You call the API live while a user waits | Address lookup, price checks, availability |
Most real systems combine them. A typical e-commerce integration might use webhooks for new orders, direct calls for live stock checks, and an overnight batch job to reconcile the day's numbers against the accounting system.
Third-party API integration vs custom API
There is an important distinction. Third-party API integration means connecting to someone else's system on their terms — Stripe, HubSpot, Xero, Shopify. You work within their rate limits, their data model, and their release schedule. Building your own API means exposing your data so other systems (or your own mobile app) can consume it. The first is mostly mapping and error handling; the second is design work, because you are creating a contract other developers will depend on.
What API integration costs
Cost tracks three things: how well-documented the target API is, how far apart the two data models are, and how bad it is if the sync fails.
| Integration type | Typical cost |
|---|---|
| Simple one-way sync, well-documented modern API | £1,200–£3,500 |
| Two-way sync with field mapping and conflict rules | £3,500–£9,000 |
| Multi-system integration (3+ platforms, orchestration) | £9,000–£30,000 |
| Legacy or undocumented system (SOAP, CSV/SFTP, screen-scraping) | £6,000–£25,000+ |
Legacy systems are expensive for a specific reason: without documentation, someone has to determine the behaviour experimentally, and every undocumented edge case is discovered in production. Budget contingency for anything older than about a decade.
Where integrations break
Rate limits. Every API caps how often you can call it. Hit the cap and you get 429 responses. A well-built integration backs off and retries with increasing delays; a naive one silently drops data.
Partial failure. The dangerous case is not total failure — that is obvious. It is when three of five records sync and two do not. Without idempotency (safe repeat operations) and a record of what succeeded, retries create duplicates.
Schema drift. The vendor adds a field, renames another, or deprecates an endpoint. Integrations that assume a fixed response shape break quietly. Version-pin where possible and subscribe to the vendor's developer changelog.
Credential expiry. OAuth tokens expire and refresh tokens get revoked. An integration with no alerting can be dead for a fortnight before anyone notices the CRM has stopped updating.
Timezone and encoding. Unglamorous, endlessly recurring. Store timestamps in UTC, convert only at display, and be explicit about character encoding at every boundary. You can sanity-check timestamp conversions with our timestamp converter.
What to specify before you commission one
Answer these before development starts and you will avoid most of the expensive surprises:
- Direction of truth. If both systems change the same record, which one wins?
- Latency tolerance. Must it be instant, or is every 15 minutes fine? Real-time costs more.
- Volume. Ten records a day and ten thousand an hour are different architectures.
- Failure behaviour. Retry silently, queue for later, or alert a human?
- Field mapping. Where exactly does each field land, and what happens to fields with no home?
- Monitoring. How will you know it broke — before a customer tells you?
Integration platforms vs custom code
Tools like Zapier and Make connect popular systems without engineering, and for simple, low-volume, non-critical flows they are the right answer. They stop being the right answer when you need conditional logic across several steps, high volume (per-task pricing scales badly), custom data transformation, or an audit trail you control. The switching point is usually somewhere between one and three thousand tasks a month — we cover the trade-off in detail in Zapier vs custom automation.
The honest summary: an integration is not finished when data moves once. It is finished when it keeps moving unattended, tells you when it cannot, and never quietly loses a record.