What is API integration? A plain-English guide for business leaders

If you're an MD, ops director or business owner, you've probably sat in a meeting where someone said "we just need to integrate these two systems" – and the project then took six months, cost twice what anyone expected and still doesn't quite work. Or you've heard the opposite pitch: "it'll only take a few days." Neither instinct is usually right.

This guide explains what API integration actually is, what it involves in practice and how to think about the build-vs-buy decision before you commit budget or time to it.

What an API actually is

An API – Application Programming Interface – is a defined way for two software systems to talk to each other. Think of it as a contract: system A agrees to send requests in a particular format, and system B agrees to respond in a particular way. Neither system needs to know how the other works internally. They just need to agree on the language between them.

The most common type you'll encounter is a REST API – which uses standard web protocols and works like a structured request-response conversation between systems. When your e-commerce platform asks your accounting software "give me the order with ID 4521", the accounting software sends back a structured response containing exactly that data. REST APIs underpin most modern software integration.

A related concept worth knowing is a webhook – essentially a push notification from one system to another. Instead of one system repeatedly asking "any updates?", the sending system calls you the moment something happens. A payment processor might send a webhook to your CRM the instant a payment completes, triggering an automated follow-up. Webhooks are more efficient than constant polling and are the right tool when you need near-real-time data flow.

An endpoint is the specific address where an API receives a request – for example, /api/orders might return order records, while /api/customers returns customer data. Each endpoint does a specific job, and a well-documented API will list all of them clearly.

What integration solves in practice

The business case for integration is almost always the same: data that lives in one system needs to be in another, and right now someone is moving it by hand. That manual step creates lag, errors and staff time spent on work that has no business value.

Some concrete examples:

• CRM to email marketing. A new contact added to your CRM automatically appears in the right audience segment in your email platform. No CSV exports, no manual imports, no delay between someone enquiring and receiving your welcome sequence.
• E-commerce to ERP. An order placed on your website flows directly into your ERP or accounting system – stock levels adjust, the invoice generates and the fulfilment team can see it without anyone re-typing order details.
• Booking engine to property management system. A reservation made through an online travel agent lands directly in your PMS, room availability updates across all channels and the guest record is created without front-desk staff manually processing it.
• Website form to CRM. A prospect fills out a contact form and their details – name, company, enquiry type – are created as a lead record in your CRM instantly, with the right owner assigned and the clock started on your follow-up SLA.

In each case the value isn't technical. It's that your team stops doing data entry and starts doing higher-value work. Errors caused by re-keying disappear. Reporting becomes more reliable because there's a single source of truth rather than several systems that are never quite in sync.

Build vs buy: native integrations, iPaaS and custom builds

There are three broad tiers to consider before anyone writes a line of code.

Native connectors are built-in integrations that ship with your software. Salesforce connects directly to Mailchimp. Shopify has a native integration with Xero. HubSpot connects to dozens of tools out of the box. If both systems you want to connect are popular enough, there's a reasonable chance a native connector already exists. Always check here first – it's free, it's maintained by the vendor and it requires no development resource to set up.

iPaaS platforms – integration platform as a service – are middleware tools that sit between your systems and handle the translation. Zapier, Make (formerly Integromat), Boomi and Workato all fall into this category. You build flows visually, without writing code, and the platform manages the connection. For standard data flows between common software tools, these are often the right answer – fast to set up, low cost at modest volumes and easy to modify. Their limits appear at scale (rate limiting – the number of API calls a system allows per hour – can become a constraint), with complex conditional logic or when you're connecting bespoke or legacy systems that these platforms don't support.

Custom API development is the right choice when the other two options don't fit. That's typically because one of your systems is bespoke, or because the logic involved – how data is transformed, what triggers what, what happens in error cases – is genuinely complex. Custom builds take longer and cost more upfront, but they give you full control and no dependency on a third-party platform that could change its pricing or retire a connector.

The honest answer is that many businesses over-engineer this decision. If a native connector or a well-configured Zapier flow does the job, use it. Custom development is for the problems those tools can't solve.

What integration projects actually involve

This is where expectations most often diverge from reality. "Connect system A to system B" sounds simple. In practice, several layers of work sit underneath that statement.

Data mapping is the process of defining which field in system A corresponds to which field in system B. A customer's "first name" in your CRM might need to map to "contact_first" in your email platform – and someone has to define that for every field being transferred. When the two systems use different formats (dates are a classic example), someone has to handle the conversion too.

Authentication means establishing that your integration has permission to access both systems. Most modern APIs use token-based authentication, but the setup varies and tokens expire, which means your integration needs to handle renewal gracefully.

Error handling is often the part that gets underestimated most. What happens if system B is unavailable when system A sends data? Does it retry? How many times? What happens to the data in the meantime? Does someone get alerted? A good integration handles failures silently and recovers automatically. A poor one fails silently and corrupts data, or alerts every ten minutes and trains your team to ignore the alerts.

Monitoring means you have visibility into whether your integration is working. Volume metrics, error rates, latency – the information you need to know that data is flowing as expected and to catch problems before they become business issues.

Maintenance is ongoing. When either system updates its API – which they all do eventually – your integration may break. Deprecations, version changes, authentication changes: these are normal parts of the lifecycle and should be budgeted for.

How to scope an integration project

The cleaner your brief, the faster and cheaper the build. Before you go to a developer, you should be able to specify:

• What data moves. List the specific fields – not just "customer records" but which fields within a customer record, and whether you need all of them or a subset.
• In which direction. Is it one-way (A sends to B) or bidirectional (changes in either system should sync to the other)? Bidirectional integrations are significantly more complex.
• How often. Real-time (triggered by an event), near-real-time (webhooks), or batched (a nightly sync of all changes from the day)?
• What triggers it. A new record created? A status change? A form submission? A scheduled time?
• What happens on errors. Who gets notified, what's the retry policy and what's the acceptable data loss window?
• How you'll monitor it. Do you need a dashboard? Email alerts? What does "working" look like in measurable terms?

If you can answer all of these before the first technical conversation, you'll get better estimates, faster delivery and fewer surprises.

Signs your integration approach needs rethinking

Integration debt is as real as technical debt, and it accumulates in similar ways. These are the warning signs:

Integration sprawl. Dozens of point-to-point connections built over time by different people, with no central picture of what connects to what. When one system changes, nobody knows what breaks until something does.

Brittle connections. Integrations that work until they don't, with no clear owner and no monitoring. The first sign of a problem is a user noticing data is wrong – days after it went wrong.

No monitoring. If your team can't tell you how many records flowed through your integrations last week, or what the error rate was, you don't have integration – you have hope.

Manual fixes as standard operating procedure. If part of someone's job involves regularly checking an integration and manually correcting data it got wrong, the integration isn't working. It's just moved the problem from one place to another.

These problems compound. A business that's been integrating systems piecemeal for several years often reaches a point where the integration layer is more fragile than the systems it connects.