How Interfaces Let Separate Systems Talk to Each Other

Four Systems That Know Nothing About Each Other

In many companies the online shop runs in one program, customer care in the CRM, invoices in accounting and shipping with a service provider. Each tool does its job. The problem appears at the borders in between.

An order arrives in the shop. Someone types the customer details into the CRM, creates the invoice in accounting and enters the shipping job in the fourth tool. Four programs, the same data, typed out four times. That costs time and produces typos that later surface as a wrong delivery address or a wrong invoice amount.

This is exactly the gap that interfaces close. They let programs talk to each other directly, so an order is created once and travels through the chain on its own.

What an API Really Is

API stands for Application Programming Interface. Behind the bulky term sits a simple idea. An API is an agreed language through which two programs speak to each other.

An API is the menu of a restaurant. It defines what can be ordered and what comes back, without the guest ever entering the kitchen.

The guest (one program) reads the menu, places an order and receives a defined result. How the kitchen (the other program) works inside stays hidden, and it does not matter. What matters is only that the order is placed in a form both sides understand.

Most modern web interfaces speak over HTTP, the same protocol the browser uses to load pages. A request consists of an address, a method and usually a data package. The table below shows the four basic operations.

JSON, the Format Behind the Exchange

For two programs to understand data, they need a shared format. On the web JSON has prevailed, short for JavaScript Object Notation. It is text that machines process quickly and humans can still read.

JSON describes data as pairs of key and value. An order could look like this.

{
  "order_number": "2025-4471",
  "customer": "Example Ltd",
  "amount_net": 1290.00,
  "currency": "EUR",
  "line_items": 3,
  "paid": true
}

Every line is unambiguous. amount_net is a number, paid a truth value, customer a text. This clarity is what lets accounting take over the amount correctly, without having to interpret it. The older format XML does something similar, but it is far more verbose and has become rarer in modern web interfaces.

Webhooks, When the System Speaks Up by Itself

With a classic API one program actively asks whether something new exists. It calls the interface at regular intervals and checks the state. This method is called polling. It works, but it wastes requests, because most checks return the answer that nothing has changed.

Webhooks turn the principle around. Instead of asking, the recipient gets notified. As soon as an event occurs, for example a successful payment, the triggering system sends a data package on its own to a stored address. The recipient reacts at once, without having asked first.

The difference can be pinned to numbers. Polling every five minutes produces around 288 requests per day, most of which come up empty. A webhook fires only when something actually happens, so perhaps twelve times on the same day. Less load, fresher data.

• Polling asks actively and on a fixed beat, regardless of whether anything is new.
• A webhook reports only on the actual event and delivers data closer to real time.
• Polling is robust when the recipient is not always reachable, webhooks need a reliably reachable endpoint.

Failure Cases and Why Idempotency Counts

Interfaces run over networks, and networks fail. A request goes out, the answer does not come back, even though the order was in fact recorded long ago. If the system now sends the request again, a duplicate order looms.

This is where idempotency comes in. An idempotent interface recognizes a repeated request and does not carry it out a second time. The common approach is an idempotency key, a unique identifier the sending system includes. If the same key arrives twice, the recipient answers with the result of the first attempt instead of creating a new transaction.

At least as important is the right handling of response codes. HTTP returns them as three-digit numbers.

A 400 is an error on the sending side and does not improve through repetition. A 500 or 429 is often temporary, and here a retry with growing intervals helps, the so-called exponential backoff. Separating the two cleanly and securing them with idempotency builds a chain that survives a short outage without doing harm.

The Benefit When Data Flows on Its Own

A connected chain changes daily work noticeably. The order is created once in the shop. From there the customer moves into the CRM, the amount into accounting and the job to shipping, without anyone typing anything. What used to cost several minutes of manual transfer per order now runs in seconds and without typos.

This lowers not only the effort but also the error rate. A delivery address entered only once cannot slip on the third retype. Data that flows automatically is also more current, because no one waits for the next free moment to transfer it.

Anyone transferring personal data between systems needs a legal basis under Article 6 of the GDPR, in a business context usually the performance of a contract. Interfaces should pass only the fields the purpose truly requires, and the transfer should run encrypted over HTTPS. Data minimization is not an obstacle here but clean engineering.

Such a connection cannot be ordered off the shelf. It begins by understanding the systems and their data flows before the first line is written. This order, first understand, then plan, then build, then extend, is the thread behind everything we build, and it is described in full on our Mission page.

Conclusion

An API is not magic but an agreed language between programs. Webhooks deliver events closer to real time, JSON keeps the data clear and readable, and idempotency makes sure a broken attempt does no double damage. Together these building blocks solve the basic problem of separate systems. Data is no longer copied by hand, it flows.

---

Are shop, CRM, accounting and shipping still running apart? We look at the data flows and show which interface saves the biggest manual step.