Webhook Retries & Inbound Redelivery

Webhook deliveries that fail with a server error, a 429, a timeout, or a dropped connection are now retried for about 16 minutes instead of failing on the first answer, and any inbound document can be redelivered to your webhook without resubmitting the EDI.

Impact: if your endpoint goes down briefly, for example during a deploy, documents that arrive in that window now reach you once it is back, with nothing to do on your side. Because a delivery can now arrive more than once, make your handler safe to run twice for the same X-Request-ID. If you recover failed deliveries by polling the feed for errors and resubmitting the X12, you can use Redeliver instead, which keeps the original transaction and trace.

What is retried:

• A 500, 502, 503, or 504, a 429, a timeout (the limit is 10 seconds), or a connection that is refused, reset, or closed before a response.
• Each delivery gets 6 attempts in total. The waits between them are about 3 seconds, 18 seconds, 83 seconds, 4 minutes, and 10 minutes.
• A Retry-After header on a 429 or 503 can make a wait longer, up to 10 minutes. It never makes a wait shorter.
• Any other 4xx, any other 5xx such as 501, a DNS or TLS failure, and a redirect are still final on the first answer.
• An error result and an error feed entry are written once, when the last attempt fails. The attempts before it appear on the trace as log lines only.

What your endpoint receives:

• X-Request-ID is now the same on every attempt of one delivery. Use it as the idempotency key: a 502 from your gateway does not prove your handler never ran.
• A new X-Webhook-Attempt header gives the attempt number, from 1 to 6.
• The body’s timestamp is now when the result was ready for delivery, so the body is identical on every attempt. It used to be the send time. The send time is still the t value in X-Webhook-Signature, which is the value you sign with.

Redelivery:

• Inbound transactions now have a Redeliver button on their page, in the place where outbound transactions have Resend. The API equivalent is POST /platform/edi_transactions/:id/redeliver, which answers 202 once the redelivery has started.
• Redelivery repeats the delivery on the same trace. It does not parse the document again, does not create a new transaction, and does not count toward billing. The body carries the same resultId as the original, with a new X-Request-ID.
• It works whether or not the original delivery failed, for the case where your side lost a document after answering 2xx.
• The redeliver endpoint refuses outbound transactions with not_inbound, and the resend endpoint still refuses inbound transactions with not_outbound. A redelivery is also refused when the stored data is past the 45-day retention (content_unavailable), when the document failed before it reached delivery (delivery_not_reached), and for poll-only partners (poll_delivery).
• Redeliver and resend share one rate limit of 10 requests per minute per API key. Redelivery is also available as the transaction_redeliver MCP tool and as tedi transaction redeliver <id>.

Limits:

• The error webhook, which notifies you of a failed result, is not retried. It gets one attempt.
• A redelivery does not resend the 997 for the document. Resend that from the 997’s own transaction page.

Retries are covered in the webhook docs, and redelivery in the EDI transaction docs.

This update was written with AI assistance. It has been reviewed and edited by a human.