What is API integration, and when do you need it?

An API is a defined interface that lets two programs talk to each other. In non-technical terms, it is a shared language and a shared form structure for passing information around.

Integration is the act of using that interface to connect two systems.

When do you need it?

You need it if you find yourself saying: "We take this information from over here and type it in over there."

Typical examples:

• Writing e-commerce orders into your accounting software.
• Sending order details to a courier and pulling the tracking number back.
• Dropping website form submissions into your CRM.
• Managing stock across several marketplaces from one place.
• Exposing your own stock and pricing data to your dealers.

All of this can be done by hand. The problem is that as volume grows, doing it by hand becomes both slow and error-prone.

There is a simple threshold for the decision: if you enter the same data in two places more than ten times a day, integration pays for itself quickly.

"Does our software have an API?"

One of three situations applies.

There is an API and it is documented. The best case. You connect directly, usually within a few days.

There is an API but it is undocumented or limited. Workable, but discovery takes longer. Most local accounting and ERP products fall into this group. You will usually need to request documentation from the vendor, and that exchange can stretch over several weeks.

There is no API. In that case you can use scheduled file transfers, direct database access, or a bridge that works through the interface. More fragile, but possible.

Tell us the product name and we can usually tell you within a day which situation you are in.

One-way or two-way?

This is the single decision that most affects cost.

One-way transfer writes data created in one system into another. The order is created in e-commerce and flows to accounting. It is simple and predictable.

Two-way sync is where both sides can change data. That raises an unavoidable question: if the same record changed on both sides, which one wins?

Two-way integrations built without answering that question corrupt data. The most practical solution is usually to assign an owner to each field: the CRM owns address information, the warehouse system owns stock levels.

Why integration projects break

Nobody decided which system is right. If the same customer has a different address in two systems, which is correct? If that question is not answered up front, the integration corrupts data on every sync.

Field mappings were never written down. "Customer name" may be a single field in one system and split into first and last name in another. Date formats, currencies, and tax number fields carry the same problem. If these differences are not documented, they turn into surprises later.

Failure was never designed. The connection dropped, the other side did not respond, the data was rejected. If a record disappears silently, it gets noticed weeks later, by which point it has piled up.

Rate limits were ignored. Most APIs allow a fixed number of requests per minute. Bulk transfers exceed that limit and get rejected. Queueing and back-off need to be built in from the start.

There is no test environment. When you work straight against live data, the first bug shows up in real orders. If the provider offers a sandbox, use it.

Three properties of a good integration

It can retry. A record that fails should be retried automatically, with increasing intervals.

It is observable. You should be able to see which record moved when, and which ones are still waiting. This screen usually ends up being the most-used part of the project.

It does not fail silently. When something jams, someone should be notified. The biggest risk in integrations is not noise, it is silence.

What drives the cost?

The number of systems, the API quality of each, the data volume, and the sync direction. Two-way sync is more than twice the work of one-way, because it requires conflict handling.

Starting with a simple one-way transfer and moving to two-way only if needed is usually the most economical path. Moving a single record type in the first release is both cheaper and faster than trying to connect everything at once.

Do not forget maintenance

An integration is never finished. When the system you connected to changes its API, the bridge has to be updated too. This cost is small but it is not zero, and it belongs in the budget.

Most providers announce changes in advance. Subscribing to those announcements keeps you from waking up to a broken integration.

---

Tell us which systems you want to connect and we can tell you whether it is possible and roughly how long it will take. Our approach is on the API and system integration page.