Webhook Timeout Windows: 7 Platforms Measured

Every carrier and shipping platform publishes a different answer to the same question: how long do you have to acknowledge a webhook before it is marked failed and queued for retry? The numbers range from a five-second window at Shopify to an open-ended cadence at FedEx that never states a response-time limit at all. If you are sizing handler timeouts, dead-letter queue (DLQ) policy, or idempotency key retention for a multi-carrier platform, guessing at these figures is a way to get paged. This post puts the published webhook timeout, retry count, and uptime numbers for seven platforms side by side, with a source for every cell.

Why the acknowledgement window is the number that matters

Your handler's synchronous work has to fit inside whatever window the sender enforces, or the delivery is marked failed and re-sent. Miss that window twice and you are processing the same event three times while your downstream system (ERP, WMS, tax engine) has no idea it already ran. This is the entire justification for idempotency keys and queue-first handlers: acknowledge fast, do the real work off the request thread. The webhook timeout figure below is the hard constraint you design against. Get it wrong and you either return 200 before you've actually persisted anything, or you time out and generate duplicates.

Ack timeout and retry count, by platform

The table below lists exactly what each vendor's own documentation states, no rounding beyond what the source gives.

Some of these are worth reading twice. Shopify expects to establish the connection and receive your response in less than five seconds or the request times out. Miss that and Shopify waits five seconds for a response to each request to a webhook, and if there's no response, or an error is returned, then Shopify retries the connection 8 times over the next 4 hours.

FedEx doesn't publish a response-time limit at all, only a retry cadence: FedEx will hold the data and attempt to resend it within a span of 3 retries within 5 minutes intervals, and if FedEx does not receive a successful response in the defined time span, then FedEx will stop redelivery of that specific event. That's a full retry cycle done inside roughly fifteen minutes, far tighter than Shopify's four hours.

ShipEngine's own webhook documentation is explicit about the acknowledgement window: when ShipEngine dispatches a webhook, it allows 10 seconds for you to acknowledge you have successfully received the payload, and if it doesn't receive an acknowledgement within 10 seconds, the system will put the payload back into the queue and make a maximum of two additional attempts to dispatch the given payload, typically separated by 30 minutes. But the ShipStation blog, covering the same product, states something different: webhook delivery will be attempted 3 times with a 2-hour delay between each attempt. Both are dated documents from the same vendor family. Rather than pick a winner, treat this as a warning: don't assume a single retry policy applies across every product surface a vendor operates, and always link to the specific doc page, not the vendor name, when you write your own runbook.

Zenkraft keeps the same 5-second ceiling as Shopify but is vaguer on count: Zenkraft has set a 5 second timeout, and any errors will be retried in a staggered manner over the course of the day. No fixed attempt count is published. Shipium is the tightest window in the set: your response must be delivered within 3 seconds of receiving the webhook call, and Shipium will retry the webhook three times if a 200-level HTTP code response is not received within 3 seconds, as required. AfterShip is the outlier on the other end. In case of an unsuccessful event, AfterShip attempts to deliver your webhooks up to 14 times with exponential backoff, and the delay itself grows fast: if the attempt fails, AfterShip will retry the 2nd attempt 30 seconds later, and if the 7th attempt fails, AfterShip will retry the 8th attempt 960 seconds later. By attempt 14 you're well past the multi-hour mark.

Method: how this table was built

Every figure in Table 1 was pulled directly from the vendor's own developer documentation or official support page, collected in August 2026. No numbers came from third-party aggregators, community forums, or scraped traffic samples. Where a vendor's own docs disagreed with itself across product lines (ShipEngine/ShipStation), both figures are shown rather than one being silently discarded. This table deliberately excludes payload size limits, signature verification windows, and delivery ordering guarantees, those deserve their own comparison and are covered separately on this blog. Where no numeric figure exists in the vendor's own material, the cell reads "Not published" rather than an estimate.

Published uptime and SLA figures

Almost none of the carriers themselves publish a numeric uptime commitment. The multi-carrier platforms that sit in front of them mostly do, because they're selling reliability as part of the product.

EasyPost's status page shows Carriers Operational at 99.84% uptime over the trailing 90 days, alongside Webhooks and API components tracked separately, and the per-carrier breakdown shows DHL Express and FedEx both at 99.85% uptime, Canada Post at 99.63%, over the same 90-day window. These are point-in-time figures pulled in August 2026; the rolling window will have moved by the time you check the live page.

What the numbers mean for handler design

If your slowest downstream write, a tax calculation, an ERP post, a warehouse sync, can exceed roughly 3 to 5 seconds under load, you cannot process it synchronously inside the webhook handler for any of the platforms above. Shopify gives you five seconds total. Shipium gives you three. Zenkraft matches Shopify at five. None of that is enough time for a chained API call plus a database write plus a queue publish, especially with connection pool contention during a peak. The design rule is simple: acknowledge immediately, queue the payload, process asynchronously, and let your worker retry against your own backoff policy rather than the sender's.

The retry counts matter just as much as the timeout. FedEx gives you roughly fifteen minutes end to end across 3 attempts before it stops trying. AfterShip gives you a curve stretching out over multiple hours across 14 attempts. If your dead-letter queue policy assumes a single global retry window, you'll either give up on FedEx events too early or hold AfterShip events in a live retry state for far longer than necessary. Idempotency-by-event-ID isn't optional here, it's mandatory, because the retry semantics differ per sender and your handler will see genuine duplicates from some carriers and none from others within the same integration layer.

This is exactly the problem multi-carrier middleware exists to absorb. Platforms like Cargoson, alongside nShift and EasyPost, sit between dozens of carrier webhook implementations and a single downstream contract, which means someone has to reconcile a 5-second Shopify-style ceiling against a FedEx cadence that never states one at all, inside the same event pipeline.

Method for the uptime table, and as-of date

The uptime figures are snapshots of public status pages and vendor blog claims collected in August 2026, not independently measured by this blog. Status page percentages roll on a 90-day window and will have shifted by the time you check the live source. Treat Table 2 as a reference point for what each vendor was willing to publish, not a live SLA you can hold anyone to contractually.

Takeaways for architects

• Build your own synthetic monitors per carrier rather than trusting a single vendor-published percentage, since only two of the seven webhook senders in this comparison publish any uptime figure, and even fewer carriers themselves do.
• Size retry and backoff policy per sender, not with one global constant. FedEx's cycle completes in minutes; AfterShip's stretches over hours.
• Treat the shortest published ack window in your integration set, not the average, as your handler's real synchronous budget.
• Log the exact retry attempt number and originating timestamp on every inbound webhook so you can tell a genuine duplicate from a sender's own backoff replay.
• Re-check vendor docs on a schedule. Shopify changed its retry policy from 19 attempts over 48 hours to 8 attempts over 4 hours in a single changelog entry, and nothing forces a vendor to notify integrators individually.