How should ERP integration timeouts and retries be handled?
A timeout does not prove that an operation failed. A practical framework for handling ambiguous outcomes without losing or duplicating orders.
· TankDev Mühendislik
A B2B portal submits an order to an ERP and waits. After a timeout, the ERP may never have received the request, or it may have recorded the order while its response was lost. Treating the second case as a new request can create a duplicate order.
Why is a timeout not a failure result?
A closed HTTP connection only says that no response arrived within the configured time. It does not describe the remote database. The user may need a separate awaiting-verification state instead of an immediate failed or completed result.
Operation identity and idempotency
Assign a unique operation key to each logical order. When the same key and payload return, return the existing outcome rather than creating a new order. Reject and investigate the same key used with different content.
- Store the operation key with the order record.
- Define its scope by account and operation type.
- Compare a payload fingerprint to detect misuse.
- Retain protection for the realistic retry horizon.
Bounded retry behaviour
Transient connection errors can use increasing waits with jitter. An ambiguous write should not be retried blindly. Query the remote status first when possible; otherwise place the record in a reconciliation queue.
What should operations see?
Show business state rather than raw error codes: transfer pending, verification required, or rejected. Staff need the reason, last attempt, and a safe reprocessing control. Keep the transitions as an audit trail.
Test before release
- What happens when the ERP records an order but sends no response?
- How many records appear when the same request arrives concurrently?
- Do queues and alerts work through a sustained outage?
- Is a reused key with different content rejected?
- Can a pending record reach the right state after intervention?
Explore the illustrative order scenario, read our system integration approach, or describe your current integration so its authority, failure states, and retry rules can be made explicit.