An API integration between your ERP and other systems: what is involved?

What an API integration is

An API is the fixed entrance a system offers to other software: an agreed way to request or pass on data. An integration uses that entrance to let two systems exchange data automatically. An order from the webshop then lands in the ERP by itself, and a changed stock level goes back to the webshop, without anyone retyping anything.

It sounds like a technical detail, but an integration is above all an agreement about your process: which system owns which data, when something goes back and forth, and what happens when it goes wrong.

Common integrations with an ERP

The need for an integration usually arises in the same places:

• Webshop and ERP: orders, customers, prices and stock, so an order is entered only once.
• Planning and ERP: orders and operations to the schedule, completions back to the ERP.
• Accounting and ERP: invoices, payments and ledger entries without double entry.
• Customer or supplier portal: partners who check the status of an order or delivery themselves.
• Transport and shipping: shipping labels, track and trace and delivery confirmations.

The questions to answer up front

Most problems with integrations do not arise in the code, but in questions nobody asked beforehand. Before anything is built, these points should have an answer:

• Source of truth. Which system leads for customers, articles, prices and stock? If two systems may both change something, there has to be a rule for who wins.
• Direction. Does data go one way, or back and forth? Two-way traffic needs more agreements.
• Timing. Does it have to be immediate, on every change, or is a few times a day enough? Not everything needs to be real-time.
• Fields. A customer in the webshop is not the same as a debtor in the ERP. Which field maps to which, and what if a field is missing on one side?
• Errors. What happens to an order that is wrong, or when a system is briefly unreachable? Who gets notified, and how is it fixed?

What determines how much work it is

How much work an integration is depends mainly on three things: whether both systems have a well-documented API, how many kinds of data go back and forth, and how careful the error handling has to be.

Connecting two modern packages with a good API is manageable work. An older ERP without an API asks for more: the exchange then runs, for example, through files dropped in a fixed location, or directly through the database. That can work fine, but needs extra attention for what happens when the ERP is updated.

Standard connector or custom integration?

Ready-made connectors or integration platforms exist for many popular packages. They are a good choice if your situation matches what the connector assumes: standard fields, a standard process, few exceptions.

A custom integration makes sense if your process differs, if logic has to sit between the systems, such as splitting an order across several locations or converting units, or if one of the systems has no standard connector. Often a combination is wisest: a connector where possible, custom work where needed.

An integration is never finished

Systems get updated, APIs change and your process grows. A good integration takes that into account: it records what was exchanged, reports when something goes wrong, and is built so that a change on one side does not bring everything to a halt. So agree up front who monitors and maintains the integration, and how you notice something is off before a customer does.

How I approach an integration

I start by mapping which data comes from where and where it has to go, and which system leads for what. Then I design the integration, including what happens when something goes wrong. You see the plan before any code is written.

I build the integration in steps and test each step before it goes live, so the systems that work well keep running. After delivery I stay available for maintenance, also when one of the systems is updated.

Frequently asked questions

My ERP has no API. Can I still connect it?

Often, yes. Many older systems can import and export files, or have a database that can be read directly. That takes more care than an integration through an API, but is quite doable in practice. Whether it works for your system becomes clear in the first conversation.

Does an integration have to be real-time?

Not always. You want stock in a webshop updated quickly, but invoices to accounting can easily go a few times a day. The more often and faster, the more the integration has to absorb, so it pays to choose per kind of data.

What happens when one of the systems gets an update?

Then the integration can be affected, especially if the API changes. A good integration reports straight away when something goes wrong, so it is fixed quickly. Agree up front who does that maintenance.