ERP5 min readNetray Engineering TeamUpdated March 4, 2025

Integration Error Handling Patterns for ERP Landscapes

Integration error handling patterns are the standard techniques that keep interfaces reliable when systems fail: retry with exponential backoff, idempotency keys, dead-letter queues, circuit breakers, compensating transactions, and reconciliation. In an ERP landscape the stakes are higher than in most software, because a duplicated message can create a second purchase order and a silently dropped one can leave a customer unshipped. The rule that organizes everything else is to classify each failure as transient, poison, or business before deciding how to respond - because retrying a poison message forever is the most common failure pattern in production.

Classify Errors Before You Design Handling

Three categories, three completely different responses. Transient failures - network timeouts, database deadlocks, an ERP app pool recycling, HTTP 429 or 503 - will succeed if retried. Poison messages - malformed payloads, missing mandatory fields, schema violations - will never succeed no matter how many times you retry, and retrying them wastes capacity and buries real problems in log noise. Business rejections - unknown item number, credit hold, closed period - are valid messages that a human must resolve, and they belong in an operational queue with business context, not in a technical error log an integration developer reads. Most troubled integration estates handle all three identically, which is why their error queues are unusable.

Retry, Backoff, and Idempotency

Retry only transient failures, and never in a tight loop. Exponential backoff with jitter - one second, two, four, eight, up to a cap - prevents a recovering ERP from being immediately overwhelmed by every client reconnecting simultaneously. Cap total attempts, typically at five to seven, then route to the dead-letter queue. Retry is only safe when the receiver is idempotent, so every message needs a stable business key the receiver can use to detect a duplicate.

Exponential backoff with jitter, capped at 5 to 7 attempts, then dead-letter with the full context
Send an idempotency key - source system plus source transaction ID - on every write operation
Receiver stores processed keys for a defined window (30 days is common) and ignores repeats
Honor HTTP 429 Retry-After headers instead of applying your own backoff over the top

Dead-Letter Queues and Poison Message Handling

A dead-letter queue is only useful if someone can act on it. Store the full original payload, headers, the complete error chain, the correlation ID, and the timestamp of every attempt - not a truncated message string. Give the DLQ an owner and an SLA, because unowned dead-letter queues silently accumulate for months and then become a data recovery project. Support selective replay so an operator can fix a root cause and reprocess only affected messages.

Persist the original payload verbatim; a truncated error message makes replay impossible
Attach a correlation ID that traces the message across every system it touched
Provide filtered replay by time window, interface, and error type - never replay everything blindly
Alert when DLQ depth exceeds a threshold or when any message ages past 24 hours

Observability, Alerting, and Reconciliation

Error handling that depends on someone reading a log file is not error handling. Instrument every interface with message counts in and out, latency percentiles, error rate by category, and DLQ depth, then alert on absence as well as failure - a nightly EDI feed that sends nothing at all is a more dangerous condition than one that errors loudly. Layer reconciliation on top, because message-level success does not guarantee end-state correctness: compare order counts, inventory balances, and invoice totals between systems daily and alert on any drift. Correlation IDs generated at the point of origin and propagated through every hop are what make the resulting investigations tractable.

How Netray AI Agents Triage Integration Failures

Netray implements these patterns as shared infrastructure rather than reinventing them per interface, so every flow inherits classification, backoff, dead-lettering, and correlation tracing by default. Our AI agents then triage the queue: they classify each dead-lettered message as transient, poison, or business rejection, group recurring failures by root cause, and route business rejections to the responsible operational team with the ERP record already identified. When a partner changes a field format or an ERP patch alters a response shape, the agent detects the pattern break across messages instead of waiting for a person to notice. Clients routinely see error backlogs drop by more than half in the first month simply because the queue becomes actionable.

Frequently Asked Questions

What is an idempotency key in system integration?

It is a stable identifier sent with every write request - typically the source system name plus the source transaction ID - that lets the receiver recognize a duplicate. The receiver stores processed keys for a defined window, often 30 days, and ignores any repeat. This makes retries safe, which matters enormously in ERP integration where a duplicate message could create a second purchase order or double an inventory receipt.

How many times should an integration retry a failed message?

Five to seven attempts with exponential backoff and jitter is a reasonable default for transient failures, then route to a dead-letter queue. Retry only transient errors such as timeouts, deadlocks, and HTTP 429 or 503 responses. Malformed payloads and business rejections should never be retried, because they will fail identically every time and will bury genuine transient failures in log noise.

What belongs in a dead-letter queue?

Messages that failed permanently or exhausted their retry budget, stored with the complete original payload, headers, full error chain, correlation ID, and attempt timestamps. A truncated error string is not enough, because replay requires the original message. The queue needs a named owner, an alert on depth and message age, and filtered replay so an operator can reprocess only the messages affected by a specific fixed root cause.

Key Takeaways

1Classify Errors Before You Design Handling: Three categories, three completely different responses. Transient failures - network timeouts, database deadlocks, an ERP app pool recycling, HTTP 429 or 503 - will succeed if retried.
2Retry, Backoff, and Idempotency: Retry only transient failures, and never in a tight loop. Exponential backoff with jitter - one second, two, four, eight, up to a cap - prevents a recovering ERP from being immediately overwhelmed by every client reconnecting simultaneously.
3Dead-Letter Queues and Poison Message Handling: A dead-letter queue is only useful if someone can act on it. Store the full original payload, headers, the complete error chain, the correlation ID, and the timestamp of every attempt - not a truncated message string.

Put this into numbers

Free interactive tools for exactly this problem. No signup to use them.

Free Tool

Supply Chain Resilience Checklist

A 30-point audit across sourcing, buffers, demand visibility, ERP data quality, and disruption response, with the highest-risk items flagged as critical.

Free Tool