In this article
An order needs to reach the ERP. The request is sent, but its response does not arrive in time. Did the order arrive, or should the transfer run again?
These handovers determine whether automation helps in daily operation. A successful demo shows the ideal path. A reliable integration also needs understandable handling of temporary outages, incomplete data and operations with uncertain outcomes.
A timeout is not a definite business state
When a response is missing, the requesting system initially knows only that confirmation did not arrive in time. It cannot automatically conclude whether the receiving system already processed the operation.
“Not sent”, “sent, outcome unknown” and “confirmed processed” are different states. Treating all of them simply as an error removes the information needed for a controlled retry or manual review.
Retries need business meaning
Repeating a query differs from creating an order again. For operations that change data, define how a system recognises work it has already processed.
Idempotence means that the intended effect of several identical requests matches the effect of one. MDN explains the concept and HTTP methods. The method alone does not resolve every question in a business workflow.
Idempotency keys are a practical example. Stripe’s documentation describes how such a key supports controlled retries for supported operations. Do not assume another API behaves the same way: examine its contract, validity periods and error handling.
Agree on three things before implementation
The operation identifier: Which identifier connects the same business operation across both systems? A customer order needs a different identity from an individual transmission attempt.
The confirmation: When is a handover complete? Accepting a request does not always mean processing has finished in the destination system.
The review process: Who takes ownership when an outcome remains uncertain? Without an owner, a technical queue can become permanent storage for unresolved work.
A short process outline can capture these decisions. It should make sense to the operational team as well as the developers.
Different failures need different handling
Resending cannot fix a missing required field. A temporary connection failure may justify another attempt later. The exact rules depend on the interface.
| Situation | Question to resolve |
|---|---|
| Required field is missing | Who corrects the record? |
| Response does not arrive | Can status be queried independently? |
| Access is rejected | Which permission or configuration is missing? |
| Requests are rate-limited | What waiting and retry rules apply? |
| The same operation arrives again | How is duplicate impact prevented? |
Also limit automatic attempts. An operation should not circulate indefinitely between systems. After the agreed limit, it needs a visible state and a defined next action.
Observability belongs in the workflow
A shared technical correlation identifier helps trace an operation through its steps. Logs should show when a handover was attempted and what response was received. Credentials and unnecessary personal content do not belong in broadly accessible logs.
The operational team often needs a different view from developers: which operations remain open, what blocks them and who owns them? Plan this information rather than relying entirely on technical error messages.
A short acceptance checklist
Test more than successful transfers. Deliberately interrupt a response, repeat an operation and submit incomplete input. Check together that the resulting state and next action remain understandable.
A useful test describes the starting situation, action, expected state and owner. “The error is logged” is not enough to explain what happens to the outstanding order.
For an existing integration, first collect actual failure cases. They provide the basis for a targeted improvement plan rather than rebuilding everything on assumption.
From an interface to an owned process
An API integration connects identifiers, states and responsibilities as well as fields. Clarifying those questions early makes implementation easier to plan.
We build these connections as part of custom software and industry solutions. A project conversation starts with your workflow, existing interfaces and the cases that still need manual attention.
Frequently asked questions
Should every failed request retry automatically?
No. The answer depends on the failure, operation and receiving system. Writes especially need protection against duplicate effects.
Does a successful HTTP response mean the work is complete?
Only if the interface contract defines that completion. Some workflows acknowledge receipt before processing continues.
What should be agreed before starting?
Identifiers, confirmations, retry rules, unresolved states and ownership. A small workflow tested together is often the best starting point.