What is an API integration?

What is an API?

API stands for application programming interface. It’s the entry point a software package opens up to other software. A person logs in and clicks buttons. Another system sends a request instead: give me today’s invoices, or create this customer. The API replies with the data or with a confirmation.

Most modern packages offer a REST API: requests over the web, with the data usually in JSON. The vendor decides which data you can read and change, and how many requests you can make per minute. You’ll find that in the package’s API documentation. More on how an API works, and what to look for when you choose software, under API.

What does the integration itself do?

An API does nothing on its own. The integration is the software that ties the APIs of two systems together. It takes care of four things:

• Which data: orders, customers, products or invoices, and which of their fields need to come along.
• The mapping: a VAT code or general ledger account goes by a different name in one package than in the other.
• The timing: every night, every fifteen minutes or straight away with every change.
• What happens when it fails: retrying, sending an alert and showing what got stuck.

Export, webhook or off-the-shelf connector?

Export and import: someone pulls a file out of one system and loads it into the other. At low volumes that works fine. But it’s still manual work, and the data is only as fresh as the last export. An API integration does the same without a person in between.

Webhook: a signal a system sends on its own when something happens, such as a new order. A webhook isn’t an alternative to an API integration, but often part of one. The webhook says something has happened; the integration fetches the details through the API and passes them on. Without a webhook, the integration has to keep asking whether there’s anything new.

Off-the-shelf connector: many packages have a marketplace or app store with ready-made connectors. They’re quick to switch on and cheaper than building. They do what their maker designed for the average customer, not what your process needs. What’s available per package is listed under integrations.

When do you need a custom integration?

If an off-the-shelf connector does what you need, use it. Do check that every field you rely on comes across, and what happens when something goes wrong. A custom integration makes sense when:

• you need to combine more than two systems;
• you need your own rules in the mapping, such as a cost centre per location;
• the standard connector is missing exactly the fields you care about;
• there’s no standard connector between your two packages at all.

What’s possible per system is set out for Exact Online, AFAS and HubSpot, among others.

Why it matters in practice

Start with the flow, not the technology. Write down what needs to go from A to B and what needs to come back. Orders one way, invoice status the other. Each direction is a flow of its own, with its own failures. Start with one: an integration that tries to handle six flows at once breaks six times in the first month, and you won’t know why.

Agree who owns it on your side, too. Systems get updates, fields change and tokens expire. Someone has to decide on the mapping tables and be the one who gets the call when a flow stops. Why the price of an integration varies so much is covered in what an integration between two systems costs.