API integrations explained, with examples.

An API integration is a connection that lets two software systems exchange data automatically. An API (application programming interface) is the set of requests a system accepts from other software, such as "create this invoice" or "send me today's paid orders". The integration makes those requests, so a paid webshop order becomes a sales invoice without anyone typing it.

When a supplier says their product "has an API", it means an integration is possible. Someone still has to build it. When they say it "integrates with" your accounting or ERP system, ask which records move, in which direction, how often, and who is told when a record fails. A nightly one-way copy of new customers and a two-way sync of orders both count as integrations, with very different amounts of work.

If the integration is one step in a larger process you want to automate, our guide on how to automate business processes covers choosing that process first.

Every exchange through an API is a request followed by a response. One system sends a request to an address the other system publishes, called an endpoint, with a token that proves who is asking. The receiving system checks the token, carries out the request and replies with the data, a confirmation or an error code.

Here is one exchange between two illustrative systems, a webshop and a cloud accounting package:

1. 01A customer pays for order 10482. The webshop immediately sends the integration a short message saying the order is paid. A message pushed like this is called a webhook.
2. 02The integration asks the webshop's API for the full order: customer, order lines, VAT and shipping.
3. 03It translates the order into the accounting package's terms: product code to item code, VAT rate to VAT code, and the customer's email address to the matching debtor.
4. 04It asks the accounting API to create a sales invoice, sending its access token with the request.
5. 05The accounting package checks the token and the data, creates the invoice and replies with a success code and the invoice number.
6. 06The integration saves the invoice number against the order and logs the exchange, success or error.

Steps 4 and 5 look roughly like this in JSON over HTTPS, the format most modern APIs use. The address, fields and values are made up for this example.

POST https://accounting.example.com/api/v1/sales-invoices
Authorization: Bearer <access-token>
Content-Type: application/json
Idempotency-Key: webshop-order-10482

{
  "customer_id": "C-2291",
  "invoice_date": "2026-09-15",
  "reference": "webshop-order-10482",
  "lines": [
    { "item_code": "MUG-BLUE", "quantity": 2, "unit_price": 12.50, "vat_code": "HIGH" }
  ]
}

HTTP/1.1 201 Created
Content-Type: application/json

{
  "invoice_number": "2026-00731",
  "status": "open"
}

201 Created means it worked. Errors use other codes, such as 401 for a wrong token, 400 or 422 for a field that fails validation and 429 for too many requests. The Idempotency-Key header tells an API that supports it to ignore a repeat of the same request, so a retry cannot create a second invoice for order 10482.

The opposite of a webhook is polling: the integration asks at a fixed interval whether anything has changed. Older systems often allow only polling, and some have no API at all, only a file export or a database. Connecting those is the work of legacy system integration.

Most integrations in finance and operations move one type of record from the system where it starts to the system that needs it next: an order, an invoice, a customer or a booking. Three typical cases show what moves and where the hard part sits.

Webshop to accounting

Paid orders become sales invoices, refunds become credit notes, and payouts from the payment provider are matched to them. E-commerce platforms such as Shopify and WooCommerce, and accounting packages such as Exact Online, publish documented APIs for this kind of flow.

The hard part is money that does not line up one to one. A payment provider often pays out once a day for many orders, minus its fees, so one bank transaction has to be matched to dozens of invoices and a fee booking. VAT for customers in other EU countries and rounding differences are the other usual sources of exceptions.

CRM to ERP

When a deal is won in the CRM, the customer and order go to the ERP so operations can deliver and finance can invoice. Payment status flows back, so the account manager can see whether the customer has paid. CRMs such as HubSpot and Salesforce, and ERPs such as AFAS Profit, document their APIs publicly.

Both systems hold customer data, so the first decision is which system owns which field. Delivery address and payment terms might belong to the ERP, contact person and deal notes to the CRM. Without that rule, an edit in one system overwrites a correction made in the other. Duplicates are the other common problem: the same company entered twice under slightly different names.

Customer portal to planning

A customer books a delivery slot or service visit in a portal. The portal asks the planning system which slots are free, reserves one and shows the confirmation. When a planner moves the appointment, the change flows back to the portal.

The hard part is timing. Two customers can try to book the last slot at once, so the planning system must reserve and confirm in one step, and the portal needs a clear message when a slot has just gone.

In all three cases, calling the API is the smaller part of the job. That is why our system integration projects start by mapping which system owns each field before anything is connected.

There are three ways to get an integration: switch on a standard connector one of the vendors offers, build a flow in an integration platform such as n8n, Make or Zapier, or have integration code written for your systems. Volume, how critical the flow is, how unusual the mapping is and who will maintain it decide which fits.

If a standard connector exists and covers your process, start there; plenty of integrations never need more. Test it first against your awkward cases, such as credit notes and partial deliveries. We build on integration platforms where they fit and write custom code where volume or logic calls for it, as our page on API integration services describes.

Most integration failures are quiet. A record never arrives, arrives twice or arrives with an empty field, and nobody notices until the month-end close or a customer complaint. Each has a known defence, and you can ask whoever builds or sells the integration which ones are in place.

Rate limits

APIs cap how many requests a client may send per minute or day. A month-end run or a bulk import can hit the cap, and the API answers 429 Too Many Requests, often with a header saying when to try again. Spread large jobs out, use bulk endpoints where offered, wait as long as the API asks and queue the remaining records so none are dropped.

Changed fields and API versions

A vendor renames a field, makes an optional field required or retires an old API version. Or someone in your own organisation adds a VAT code in one system and not the other. The integration keeps running, but records land in the wrong field or start being rejected.

Build against a versioned API where one exists and follow the vendor's deprecation notices. Check each record against the shape the integration expects, and set aside any record that does not match, with the reason. When a vendor announces a change, test it in a sandbox (a test copy of the system) before it reaches live data.

Silent failures

These cost the most, because nothing reports them. A webhook is lost because the receiving side was down for a few minutes. An access token expires and the nightly sync stops without logging a single error. An API returns a success code with an error message inside the response.

Monitor for missing activity as well as errors: if no orders have synced for two hours during opening hours, someone should hear about it. Read the response body along with the status code, alert before credentials expire, and run a periodic check for anything changed since the last run, so missed webhooks are picked up.

Retries

Temporary errors, such as a timeout or a brief outage, are worth retrying: the integration tries again by itself, waits longer after each attempt and stops after a set number of tries. Permanent errors, such as an unknown VAT code, fail however often you send them. Those go to a queue where a person sees the record and the error, fixes the cause and resends it.

Duplicates and idempotency

Retries bring their own risk. The accounting system creates the invoice, the reply times out on the way back, the integration retries, and the customer receives two invoices. Webhooks cause the same problem, because many platforms deliver each event at least once, which sometimes means twice.

The defence is idempotency: sending the same request twice has the same effect as sending it once. Use an idempotency key where the API supports one, check for an existing record with the same reference before creating a new one, and record which events are already processed.

Alerts that reach a person

An alert in a shared mailbox nobody reads does nothing. Send each failure to a named owner, with the record, the error and a way to resend it. A rejected invoice belongs with finance; a connection that is down belongs with whoever runs the integration. Group repeated errors so one outage sends one alert.

Reconciliation

Reconciliation is the last safety net, and finance teams know the habit from matching bank statements to the ledger. A scheduled report compares both systems: for example, the count and total value of yesterday's paid webshop orders against the sales invoices created in accounting that day, with every difference listed. It also catches manual edits made in one system only.

Before you accept an integration, from a supplier or your own team, ask:

• What happens to a record the other system rejects, and who is told?
• If the same event arrives twice, can it create a second invoice or order?
• How would we find out if nothing had synced for a day?
• Which system wins when the same field is changed in both?
• Is there a reconciliation report, and who reads it?
• When a vendor changes its API, who notices and who fixes the integration?

The cost of an API integration is set mostly by what surrounds the connection: how many systems and record types are involved, how good their APIs are, whether data moves one way or both, how many exceptions the process has and how much monitoring the flow needs. Ask how a quote accounts for each of these.

• Systems and record types. Customers, orders, invoices and credit notes each need their own mapping and rules.
• API quality. Clear documentation, a sandbox and webhooks speed the work up; missing fields or an undocumented API slow it down.
• Direction. Two-way sync needs ownership rules per field and conflict handling.
• Exceptions, such as partial deliveries, foreign VAT and merged customers, which each need a defined path.
• Historical data that has to be matched or migrated before live sync starts.
• Monitoring and support after go-live, including resend tools and reconciliation reports.
• Licences: connector fees, platform usage, and charges some vendors make for API access or higher rate limits.

Count the running cost as well as the build, since the systems at each end keep changing. We agree scope and cost in a written plan after discovery, once the systems, the data and the exceptions are mapped.

Can I build an API integration myself?

Often, for simple cases. If a standard connector or integration platform links two widely used tools, volume is low and a wrong record is easy to spot and fix, a capable person in your team can set it up and own it. Add the checks from the failure section, since platforms leave most of them to you.

Have it built when the integration creates invoices, payments or customer records at volume, syncs both ways, involves an older system or has to hold up in an audit.

Is an API integration secure?

It can be, depending on how it is set up. Keep credentials in a secrets manager, out of spreadsheets and email. Give each integration only the access it needs: a key that creates invoices has no reason to read payroll. Send data over encrypted connections, and verify the signature on incoming webhooks so nobody can send fake events.

Limit personal data to what the receiving system needs and keep it out of logs. Revoke keys when an employee or supplier leaves, and have a data processing agreement with whoever runs an integration that carries personal data.

What is the difference between a webhook and polling?

With a webhook, the source system sends a message the moment something happens. With polling, the integration asks at set intervals whether anything has changed. Webhooks are faster and lighter, but a message can be lost, so dependable integrations often use webhooks for speed and a periodic poll to catch anything missed.