API (Interface)

How an API works: request and response

The basic principle of almost every API is a question-and-answer game. One system makes a request to another – for example "give me all of today's orders" or "create this new customer". The system being addressed processes the request and sends back a response, for instance the requested order list or a confirmation that the customer was saved. This sequence repeats millions of times in the background without a user noticing any of it.

So that both sides understand each other, the structure and format of the messages are precisely agreed. The data is usually transferred in a machine-readable format such as JSON – a structure that programs can process easily and humans can read reasonably well too. The provider's API documentation describes which requests are allowed, which fields must be sent along and what the response looks like. For non-technical readers, the image of a waiter is enough: you order from the menu (the documentation), the kitchen (the system) prepares it, and you get back exactly what was agreed.

REST, webhook and EDI: the key distinctions

APIs differ in style and direction of transmission. By far the most widespread style today is REST (see REST API): a lean design that works over the normal web protocol HTTP, in which every resource – customer, order, item – is addressable via its own address (URL). REST APIs are considered easy to understand, easy to document and broadly supported, which is why most ERP systems and shops offer them.

An important counterpart is the webhook. With a classic API, your own system actively requests data (pull) – so it has to know when to ask. A webhook reverses the direction: as soon as an event occurs in the source system, such as a new order, that system sends a message (push) of its own accord to a stored address. Push saves constant polling and delivers events almost in real time; in practice many integrations combine both.

To be distinguished from this is EDI (Electronic Data Interchange). EDI is the older, heavily standardized way of exchanging data between companies – for instance for orders and invoices in B2B trade with large retail chains. EDI follows fixed message standards such as EDIFACT and is often a prerequisite for becoming a supplier to large chains. Modern web APIs are more flexible and easier to connect, while EDI retains its strength wherever industry standards and large trading partners require it.

What APIs are for in the ERP: connecting systems

The real benefit of an API becomes clear as soon as several systems have to work together. An online merchant typically runs a shop, sells additionally via marketplaces, handles payments through a payment service provider, ships via one or more parcel services and hands its documents over to accounting or the tax advisor. Without APIs, someone would have to retype orders, maintain stock levels separately in every channel and generate shipping labels by hand – error-prone and more expensive with every unit sold.

With APIs, the ERP takes on the role of the data hub: new orders from shop and marketplace come in automatically, stock levels are kept in sync across all channels, payment statuses flow back, shipping orders go to the service provider and tracking numbers go back to the customer, and the documents move in a structured way into financial accounting. This creates an end-to-end process from the customer's click through to the posted payment – the basis of any scalable multichannel operation.

Open APIs when choosing an ERP

Because hardly any company gets by permanently with just one system, an ERP's integration capability is a central selection criterion. An open, well-documented API determines whether future shops, tools or marketplaces can be connected at all – and at what cost. Systems with a closed or only rudimentary API quickly lead to vendor lock-in: you stay with the provider because switching or extending would be barely feasible technically.

When selecting, you should watch several points: is the API publicly documented? Does it cover the important objects – items, stock, orders, customers, documents – for reading and writing? Are there webhooks for real-time events? And are there already ready-made connections to common shops and marketplaces, or a middleware that acts as an intermediary? An ERP with a strong API does not have to be reinvented; it can be embedded step by step into a growing system landscape.

Authentication and rate limits

So that not everyone can access data at will, every serious API requires authentication. The calling system identifies itself with an access key – often an API key or a token following the OAuth procedure – which you set up once in the ERP or at the target system. Only whoever sends along the valid key receives responses; if you revoke the key, the connection is cut immediately.

In addition, providers protect themselves with so-called rate limits, i.e. upper limits on the number of requests per period. They prevent a faultily programmed or overloaded client from bringing the system down. In practice this means: data volumes and synchronizations must be designed so that they stay within the permitted frequency – an aspect that integration and implementation projects should factor in from the start.