An order is accepted in the shop, then manually transferred to the inventory management system and exported again for shipping the next morning. Every transition requires attention. It becomes even more problematic if a correction only arrives in one of the systems involved. Interfaces are intended to reduce such breaks. To do this, they have to do more than just send data from one address to another.

An API is a defined way to use functions or data from a system. For example, it describes how an order can be created or a delivery status can be queried. In everyday business life, the quality of this agreement determines whether an integration remains traceable. An achievable end point is just the beginning; Technical rules, access protection and error handling are also included.

What REST means and what it doesn't mean

REST refers to an architectural style for distributed systems. Many web interfaces are based on this, making resources accessible via URLs and leveraging the importance of HTTP methods. A resource can be an order or a customer address. JSON is a common data format, but is neither mandatory for REST nor evidence of a well-thought-out API.

HTTP distinguishes, among other things, reading with GET, replacing with PUT and various other operations. Their properties are important for integrations: A query defined as secure should not trigger any technical changes. For idempotent operations, repeated execution is intended to have the same intended effect as a single execution. The HTTP specification RFC 9110 explains these semantics. It does not follow that every endpoint implements them correctly.

First clarify data responsibility

If two systems are allowed to change the same customer address, a conflict arises that a transport protocol cannot resolve. For each important object, it should therefore be clear which system is the leading source. Other applications may adopt selected fields or keep an explicitly marked copy.

A fictitious example: Merchandise management is responsible for item numbers and sales status, while a product information system manages editorial descriptions. The shop brings together both information. Changes to the text must then not accidentally write back a different article number. Such a responsibility matrix is ​​often more valuable than a particularly extensive exchange format.

Unique keys instead of name comparisons

Names change, spellings vary and two people can have the same name. Relationships should therefore be established using stable identifiers. It must also be documented which system the identifier belongs to. An internal database number is not automatically a suitable external reference. During a migration or merge, additional mapping tables may be required.

An interface contract needs concrete examples

The description of an API should include mandatory fields, data types, allowed values, timing, and error cases. A string for an amount raises questions about currency and decimal representation. When it comes to appointments, the time zone and meaning need to be clarified: Is a delivery date a calendar day or an exact point in time?

Sample records should show a normal operation, a correction, and an invalid record. Automatically verifiable contracts and joint tests are particularly valuable. If a provider changes a status value, the receiving application must be able to recognize whether it is allowed to process it. Silently treating unknown values ​​as a default case can trigger incorrect decisions.

Query or event?

With regular polling, a system asks for changes at set intervals. This is understandable, but can cause unnecessary load or delays. An event procedure informs the remote party about an event that has occurred, often via a webhook. The notification should clearly distinguish whether it only reports a change or already contains the binding data.

A webhook is not a guarantee of one-time or ordered delivery. Network errors, retries and delays must be taken into account. For example, an application can store the event identifier, detect duplicate messages, and retrieve the current status again when necessary. What is crucial is that technical processing can be continued in a comprehensible manner even after an interruption.

Double transmission is a normal error case

Imagine that the target system has created an order, but the confirmation is lost along the way. The source system then does not know whether the system was successful. A careless retry can generate the same order again. A reliable repetition strategy is therefore required for writing processes.

Depending on the API, stable external process identifiers, idempotence keys or a targeted status query are possible. A key must match the specific operation and its content. It should also be clear how long the target will take him into account. An interface that works when successful is not yet operational if this uncertainty remains untreated.

Registration does not replace an authorization check

HTTPS protects the transmission, and a token can identify a calling service. Nevertheless, the application must check with every access whether this service is allowed to read or change exactly the requested object. The OWASP API Security Top 10 describes a lack of authorization checking at the object level as a risk in itself. An identifier that is difficult to guess is not a substitute for this check.

Access should be limited to the required scope, stored securely and exchangeable. Technical accounts need responsible people and regulated terms. Secrets do not belong in public source code files or in unprotected logs. Additionally, limits on request rates and data volumes help ensure that incorrect integration does not affect the entire application.

Make errors visible and editable

A good error log combines technical information with a technical reference. Employees should be able to identify which order is affected and whether a correction is necessary. At the same time, logs must not contain unnecessary personal content, access tokens or complete confidential documents.

For temporary errors, a limited repetition with increasing intervals can be useful. However, technically invalid data will not be correct. They belong in an editable error list with clear responsibility. Monitoring rules should also report when no data arrives for a long time. A process can stall without throwing a single visible error.

Master changes together

Interfaces continue to evolve. Additional optional fields are often easier to tolerate than renamed mandatory fields or changed meanings. A version number alone does not prevent malfunctions. What is required is an announced transition, tests with the remote station and an agreed deadline for adjustments.

Acceptance should intentionally test for interruptions, duplicate messages, and missing permissions. A data comparison after the restart is just as important. Do quantities and status match in both systems? Only these checks show whether the integration secures the entire process and not just a successful individual request.

A small acceptance matrix for integration

Before starting, both teams involved should examine the same situations. A valid order is transmitted once and appears in the target exactly once. Then the same process is sent again. The expected behavior is explicitly defined: confirm the existing status, update it in a controlled manner or reject it with an understandable message. The repetition must not randomly generate a second order.

This is followed by invalid and unauthorized requests. A missing mandatory field should provide understandable feedback and not leave an incomplete partial booking. A technically registered service without appropriate object authorization is not allowed to receive confidential data. It also checks what information the error message itself discloses. Internal access data or complete queries do not belong in public answers.

Another test breaks the connection after processing but before confirmation. This exact case shows whether status queries and repetition work together. After the restart, the technical results are compared. It's not just the number of successful HTTP responses that counts, but the state of both systems.

The results are documented with the tested version and the sample data used. If a change is made later, the same cases can be run again. This creates a small, shared contract that remains understandable even if the original developers are no longer directly involved in the project.

Networking with clear responsibility

A resilient interface combines technical rules with professional responsibility. It defines data responsibility, repetitions, error processing and changes. This effort is smaller if it is already taken into account in the concept instead of being added after the first double order.

GRITTMANN can accommodate existing data flows and design limited integrations for individual applications. A specific process should serve as a pilot. Like such connections individual merchandise management our expressly fictitious application example shows.

Sources and further documentation

Technical basics and additional information from the respective editors. Links last checked on 27.03.2026.