API integration: what is it and how does it work?

What is an API?

API stands for Application Programming Interface. It is the way software systems talk to each other: a fixed set of rules that lets programmes request or send data without a human in between.

The easiest analogy is a restaurant. You sit down, get a menu and give your order to the waiter. The waiter takes it to the kitchen, and later returns with your dish. You don't know how the kitchen works and don't need to; you only know the menu and the rules for ordering. In this story, the waiter is the API: a standardised counter between you and the kitchen.

An API has no visual layer, no buttons and no design. It is purely data passed back and forth through requests and responses. In the vast majority of modern software this happens over the HTTP protocol, the same protocol your browser uses to fetch a web page. Several styles exist beneath that: REST, GraphQL, SOAP and gRPC are the best known.

What is an API integration?

An API integration is the connection between two or more systems via their APIs. It is the concrete piece of software that makes one API talk to another, automatically, at fixed times or whenever something happens.

The difference from manual work is significant. Without an integration, someone exports orders from the webshop to Excel, then opens the accounting package and types the data in. With an integration, every new order appears in the accounts straight away, without anyone lifting a finger. The same data, a different route — and that different route scales as your business grows.

A good API integration is more than just "data from A to B". It also handles the exceptions: what do you do when system B is temporarily unavailable? What if the same order arrives twice by mistake? What if the structure of a field changes? These conditions determine whether an integration keeps working in production or quietly loses data. We cover those conditions in depth on our page on smart API integrations.

Types of APIs: REST, GraphQL, SOAP and more

Not every API works the same way. The underlying style determines how a developer works with the API — and in which cases that style makes sense.

REST API

The de facto standard of the modern web. REST works over HTTP, uses JSON for data and is easy for people to read. Virtually every SaaS tool you know — HubSpot, Stripe, Shopify, Slack — offers a REST API. If you request something via a URL, you get a structured response back. Simple in design, and covers most use cases.

GraphQL

A newer alternative, originally from Facebook. With GraphQL, the query specifies exactly which fields you want back — no more, no less. Useful for complex data models where you would otherwise need many separate REST calls. Shopify, GitHub and many headless CMS platforms offer GraphQL.

SOAP

The predecessor of REST. SOAP uses XML, is far more strictly defined and is rarely used for new builds today. You will encounter it in enterprise environments: legacy banking systems, government services and large ERP packages. A SOAP integration is more laborious, but for anyone who needs to talk to a legacy system it is often the only option.

gRPC

A binary protocol from Google, designed for performance-critical scenarios between internal services. You rarely come across it in B2B integrations — more often within the architectural framework of a SaaS product itself.

WebSocket

Not request-response, but a persistent open connection over which both sides can send data at any moment. Essential for chat applications, dashboards that must update live, or trading platforms.

Webhooks

Strictly speaking not an API style but a mechanism: instead of you repeatedly asking "is there anything new?", the source system sends a signal as soon as something happens. An order, a payment, a status change — pushed directly to your own endpoint. Webhooks are the standard for event-driven integrations.

Choosing between these styles is rarely a matter of principle: you use what the vendor offers. It is, however, wise to check what a SaaS vendor supports before promising an integration. An older package that only offers SOAP calls for different work than a modern tool with REST and webhooks.

How does an API integration work technically?

Under the bonnet, every API call goes through the same steps. For decision-makers it is useful to understand these in outline — not to build them yourself, but to ask the right questions of a provider.

Authentication

An API needs to know who is knocking. The three most commonly used methods are API keys (a long secret key sent with every request), OAuth 2.0 (a token flow in which a user explicitly grants permission) and JWT (a signed token carrying the identity). OAuth is the standard for user-facing integrations; API keys suit server-to-server connections.

Request

The request consists of an HTTP method (GET to retrieve something, POST to create something, PUT or PATCH to modify something, DELETE to remove something), a URL that identifies the resource, and an optional body containing data.

Response

The response contains a status code (200 = good, 4xx = your error, 5xx = their error) and a payload with the requested or confirmed data, usually in JSON.

Rate limits

Almost every API limits the number of requests per second, minute or day. If you exceed that limit, you may temporarily receive no response or even be blocked. A well-built integration takes those ceilings into account and builds in delays where necessary.

Error handling and retries

Networks falter. Servers go briefly offline. A production-grade integration retries failed requests with increasing intervals (exponential backoff) and stores what failed so it can be processed later.

Pagination

With large datasets, an API doesn't deliver everything at once. You request one "page" at a time (for example, 100 records per request) until you reach the end. Forgetting to paginate is a classic reason an integration works perfectly in testing but misses data at real volumes.

Idempotency

A well-designed API lets you send the same request multiple times without it being processed twice, for example by including a unique key per order. This is essential for payments and orders. Without idempotency, a customer may in the worst case be charged twice or the same invoice may end up in the accounts twice.

Versioning

SaaS vendors update their APIs regularly. Usually old versions keep working for a time, but eventually they expire. A production integration actively monitors vendor announcements and plans the upgrade path in advance, otherwise you risk synchronisation suddenly stopping.

Examples from practice

A few integrations we often come across in practice, familiar to SMEs and scale-ups:

• CRM → accounting: a new customer in HubSpot or Pipedrive automatically appears as a contact in Exact, Twinfield or Moneybird. No duplicate entry, no incorrect address fields.
• Webshop → ERP: a Shopify or WooCommerce order flows directly into the ERP or inventory system (SAP, Magento, Picqer). Stock, order status and invoicing stay in sync.
• ATS → payroll: when a candidate is hired in Bullhorn or Recruitee, their employee record is created directly in NMBRS or AFAS.
• WhatsApp → CRM: incoming customer messages appear as tickets in Zendesk, HubSpot or Freshdesk, including the full conversation history.
• Calendly → CRM: a scheduled appointment automatically updates a lead stage and sends the appropriate follow-up.
• Payment provider to accounting: linking Mollie, Stripe or Adyen payments to invoice statuses, so a received payment immediately closes the open item.

The biggest gains rarely come from a single integration, but from how systems work together. Three to six systems feeding each other, rather than isolated silos. If you want to see how we approach this, have a look at our page on integrations as a service.

One nuance that often gets lost in these lists: not every integration needs to be real-time. For an accounting integration, a nightly batch is often fine, and cheaper to build. For a payment confirmation in a webshop, it needs to happen within seconds. Make that trade-off per flow, not as a blanket policy for the whole organisation.

iPaaS versus custom API integration

An API integration doesn't always have to be custom-built. So-called iPaaS platforms (Integration Platform as a Service) exist that standardise much of the work.

iPaaS: Zapier, Make, Workato, n8n

With an iPaaS, you build an integration in a visual editor: a trigger from system A, an action to system B. For simple scenarios, that is quick, inexpensive and possible without writing code. It's excellent for automating standard flows between commonly used SaaS tools.

Custom integration: your own middleware

Once the logic becomes more complex — extensive field-by-field mapping, business rules, fraud checks, performance requirements or a bespoke ERP — iPaaS reaches its limits. You then build (or commission) your own middleware layer: a small piece of software that handles the translation between systems, provides monitoring and manages queuing.

It is not an either/or choice: many organisations combine the two. A Zapier flow for the simple work, custom middleware for the business-critical processes. We cover the detailed differences between the two approaches in our guide to APIs versus integration platforms.

Which businesses benefit from API integration?

The tipping points in our experience:

• SMEs with three or more standalone SaaS tools: as soon as people are retyping data between packages every day, an integration almost always pays for itself.
• Scale-ups in growth mode: what can be handled manually with a hundred transactions breaks down at a thousand a day. Integrations enable growth.
• Enterprises with a multi-vendor stack: large organisations rarely run on a single package. Integrations keep ERP, CRM, HR, finance and BI aligned.
• Industry bodies and marketplaces: when you exchange data with partners, suppliers or members, an API integration is the scalable solution for what once happened over email and spreadsheets.

We work both with SMEs considering their first integration and with enterprises looking to consolidate their existing integration landscape. For background on this, see our systems integration specialist page.

What does an API integration cost?

There is no fixed price, and anyone who quotes you one without first understanding the scope is selling you a fairy tale. What we can say is how the cost range builds up:

• iPaaS integration: a simple flow between two well-known SaaS tools sits at the lower end of the budget. No middleware needed, little business logic, mostly configuration work.
• Custom integration: costs scale with the number of systems, the complexity of the mapping, how many exceptions need handling, and industry requirements (finance, healthcare and government impose additional demands).
• Maintenance: every integration needs upkeep. API versions change, vendors adjust fields, and your own processes evolve. Plan for ongoing maintenance costs, as a percentage of the build cost rather than a fixed figure.

The biggest pitfall in a budget is forgetting monitoring and error handling. Delivering an integration that works is inexpensive; an integration that is still processing data reliably a year from now takes a little more.

Two hidden cost items people often overlook: documentation and knowledge retention. If the builder leaves and nobody knows how the mapping works, you'll end up paying to redo the integration later. For every integration, ask for a short technical readme covering the endpoints, the fields and the exceptions. That document is worth more than an extra feature.

GDPR and compliance in API integrations

As soon as personal data passes through an API — names, email addresses, phone numbers, customer numbers, payment details — the GDPR applies in full. Several points you should expect to see in any serious integration:

• DPA with every party: a data processing agreement with the vendor or iPaaS platform that handles the data.
• Encryption in transit: all traffic over TLS (HTTPS). No plain HTTP, no unencrypted queues.
• Audit log: who requested, changed or forwarded what. Essential in the event of incidents or access requests.
• Data minimisation: only pass on what you actually need. Not "the entire customer profile, just in case".
• Retention periods: if the middleware temporarily buffers data, a retention period should be set for it.

For sectors with additional frameworks (healthcare, finance, government), specific requirements apply on top of these. A serious integration partner raises these proactively.

Common mistakes in API integrations

Almost all the problems we encounter fall into the same handful of categories:

• No respect for rate limits: the integration floods requests until the vendor shuts off access. Everything then grinds to a halt.
• No error handling: when something fails, nothing is logged and nothing is retried. Data disappears into thin air.
• Hardcoded credentials: API keys in the source code or in a Git repository. One leak and you have a security incident on your hands.
• No logging or monitoring: you only discover a fault when a customer calls. By then it is too late.
• No idempotency keys: when something stalls, the same order is processed twice, and you find out in the accounts.
• Overly tight coupling: a change in one system immediately breaks five other processes. A good integration isolates that.

None of these pitfalls are exotic, and each one is avoidable. The difference lies in the discipline of whoever builds the integration and in a serious approach to testing and monitoring.

A further point that is often underestimated: testing on production-like data. An integration that works with three test customers can still fall over on real volumes because of edge cases, such as special characters in names, empty fields, or customers who were once created with a different structure. Plan a phase where the integration runs in parallel with the current process before you switch over for good.

Do it yourself or outsource?

Not every integration needs to be outsourced. A few rules of thumb:

Do it yourself

You have a simple flow between two SaaS tools, an in-house developer or a tech-savvy operations colleague, and no critical processes or large volumes at stake. A Zapier or Make flow is often sufficient in that case.

Outsource

It becomes more complex once several systems come together, when custom middleware is required, when GDPR requirements are strict, or when the integration becomes part of your core process. That's when it makes sense to bring in a partner who oversees the whole picture, from architecture through monitoring to maintenance.

There is plenty of room between those two extremes. A popular route is this: an external party builds and documents, and an internal colleague manages afterwards. Which split suits your organisation depends mainly on what you want to keep in-house. You can find more articles on these kinds of choices in our knowledge base.

Frequently Asked Questions

What is an API in one sentence?

An API is a set of agreements that lets two software systems request or send data to each other in a structured way, without a human in between.

What is the difference between an API and an API integration?

The API is the counter: the set of rules a system exposes. An API integration is the concrete piece of software that connects system A's counter to system B's, so data flows between them automatically.

What is the difference between REST and GraphQL?

REST returns a fixed response per endpoint (all fields of a resource). GraphQL lets the query determine which fields you get back, which is handy for complex data models. REST is the broader standard, while GraphQL is stronger for specific front-end or mobile scenarios.

How much does an API integration cost?

That depends on the number of systems, the complexity of the business logic and the requirements around compliance and monitoring. A simple iPaaS integration sits at the lower end of the spectrum; a production-grade, multi-system integration with its own middleware sits considerably higher. Always arrange a scoping conversation before requesting a quote.

Is an API integration GDPR-proof?

Not in itself — it has to be set up properly. With a DPA, TLS encryption, audit logging and data minimisation, an API integration can be fully GDPR-compliant. The responsibility lies with you as the data controller, together with your integration partner.

How secure is an API integration?

Secure once the basics are in place: authentication via OAuth 2.0 or securely managed API keys, TLS on all traffic, no credentials in source code, rate-limiting against misuse and monitoring for unusual patterns. Insecure as soon as any of those elements is missing.

How do I get started with an API integration?

Start with the question: which manual tasks could realistically be automated? Map out which systems are involved, whether they offer an API, and what the business value is. With that list in hand, a first conversation with an integration partner becomes far more focused — and you can judge for yourself whether an iPaaS or a custom build is the better route.

How long does it take to build an API integration?

That varies widely. A simple iPaaS flow between two common SaaS tools can be set up in a few working sessions. A custom integration across several systems, with field-level mapping, monitoring and compliance requirements, takes a multi-sprint project. Lead time is rarely the bottleneck; clarity on scope and access to the API credentials usually is.

What happens when an API changes?

SaaS providers usually announce API changes well in advance. A good integration partner monitors those announcements, schedules the migration and tests the upgrade path. Without that kind of structured management, you often only discover a breaking change on the day the old version is switched off.