What happens when an integration fails?

Can you keep taking orders?

Yes. A store saves an order in its own database and needs nothing from the ERP to finish checkout. When the integration or the ERP is down, the store keeps selling. What stops is the traffic between the systems, and each flow fails in its own way.

Orders are the flow where nothing may be lost. Stock is the flow where the delay itself does the damage: an order that arrives three hours late is still an order, a stock figure that is three hours old has already been sold against.

What happens to the messages

In an integration with a queue, a message is stored before it is sent and removed only after the receiving system confirms it. A failed attempt leaves the message where it is. Five things then decide the outcome.

Which errors are retried. A timeout, a 429 Too Many Requests and a 503 Service Unavailable pass by themselves. A 400 for an inactive item or a missing required field comes back identical on every attempt.

Backoff. The pause between attempts grows. An example schedule with five retries: 1 minute, 5 minutes, 15 minutes, 1 hour, 2 hours. Added up that is 201 minutes, so a message survives an outage of 3 hours and 21 minutes before it is given up. Retrying every second for three hours would be 10,800 calls per order against a system that is already in trouble.

A cap on attempts. After the last retry the message moves to the dead-letter queue. It keeps its original payload, so nothing has to be reconstructed from the store later:

{
  "flow": "orders-to-erp",
  "attempts": 6,
  "first_attempt": "2026-10-02T13:00:12Z",
  "last_error": "400 Item KB-2210 is inactive",
  "payload": {
    "order": "#10482",
    "customer": "Bakker Installatie B.V.",
    "lines": [ { "sku": "KB-2210", "quantity": 12, "price": "17.08" } ]
  }
}

Replay. Once item KB-2210 is active again, the message is sent again from the dead-letter queue and processed as a new order.

One order per order. A retry after a timeout is the classic source of a second sales order: the ERP created the first one and the confirmation got lost. The integration sends the store order number as an external ID and checks for it before it creates anything. More on this in duplicate customers and duplicate orders; the retry mechanics per system are in API throttling, 429s and backoff.

The sending side gives up at some point too. Shopify waits 5 seconds for an answer to a webhook, retries 8 times over 4 hours and then removes a subscription that was created through the Admin API. If the receiving end is down for an afternoon, the messages of that afternoon are gone and no new ones follow. A scheduled run that asks for all orders since the last processed one recovers them, as described in webhooks are not a guarantee.

After recovery the backlog has to pass through the same rate limit as normal traffic. 120 orders at 4 calls each are 480 calls. Against an ERP that allows 60 calls a minute, the backlog takes 8 minutes if nothing else runs.

When the two systems disagree

A failure is not always an outage. Both systems are up, both hold a value for the same field, and the values differ. Three cases come up in every store to ERP integration:

• A customer changes the delivery address in the store at 10:02. Customer service corrects the same address in the ERP at 10:04. The sync runs at 10:05.
• The ERP pushes a new price of 12.50 while a customer has the item in the cart at 11.90.
• The warehouse sells the last piece at 14:00. The store sells the same piece at 14:01, before the stock update arrives.

The outcome has to be predictable, and that takes one rule per type of data:

Last write wins needs clocks that agree. A store timestamp in UTC and an ERP timestamp in local time without a zone are two hours apart in summer in Amsterdam, and the wrong edit wins.

How you find out

An outage is the easy case: every call fails and the queue grows. A healthcheck that runs every five minutes looks at two things, the time of the last successful run and the number of messages waiting, and sends an alert to the place where the team already works. In the three-hour example the alert goes out at 13:05, five minutes after the first failed order.

The failures that cost more are the ones without an error. Standard connectors and iPaaS platforms document several of these in their own help pages:

Each of these has the same shape: the integration reports success and the data is wrong. A check on the result finds them: a daily comparison of counts and values in both systems, per flow.

Targets to hold an integration to

"It works" is not measurable. Three figures are, and they can be read from the log of any integration that keeps one:

The sum for the last row: 2% of 12 is 0.24, about one order every four months that someone types in by hand. The values are examples. The point is that each one is a number that a log can confirm or contradict.

Failure responses and a NetSuite retry example

Systems go down, time out and throttle. The integration is built so that a failure delays data and never loses it.

A rate-limited answer from NetSuite's REST API looks like this:

HTTP/1.1 429 Too Many Requests
Content-Type: application/json

{
  "title": "Too Many Requests",
  "status": 429,
  "o:errorDetails": [
    {"o:errorCode": "CONCURRENCY_LIMIT_EXCEEDED"}
  ]
}

A Standard NetSuite account allows 5 concurrent requests, shared by every integration on the account. The order waits for a free slot instead of failing. An order retried after a timeout carries the same external ID, so NetSuite updates the existing sales order instead of creating a second one.

What this means for your integration

We build every integration with a queue, retries with growing pauses, a check against duplicates and a dead-letter queue, and then we host and run it. Monitoring is part of that: a failed run raises an alert on our side, and we fix it when the cause is a changed API or a changed file on the source side. In the dashboard you see each message with its attempts and its final state, and you can look up what happened to a single order.

The conflict rules per type of data are set with you before go-live, and a dry run shows what the integration would change before it writes anything. That part is described on dry run and approval. The flows themselves are on integrations, and the order flow with its fields on orders, customers and shipping. Tell us which systems you run and what went wrong last time.