Webhook Delivery Reliability for Headless Commerce Backends: Shopify, Stripe, and NetSuite Compared on Retries, Idempotency, and DLQ Patterns (2026)

Webhooks are how a headless commerce backend learns about the events that move money, change inventory, and update the customer record. A Shopify Plus storefront paired with Stripe for an additional payment surface and NetSuite for the order management system runs hundreds to thousands of webhook events per day across the three platforms, and the correctness of the entire pipeline depends on the worst behaved platform's reliability. The three platforms have radically different webhook reliability stories, and the differences show up at the worst possible moment: the day the pipeline drops an order, double-charges a customer, or fails to deduct inventory after a refund.

We have shipped headless commerce backends that integrate all three platforms at the order management, payment, and ERP layers, and the integration patterns are not interchangeable. The retry policies, the idempotency guarantees, the ordering guarantees, the signing schemes, and the dead letter queue patterns all differ in ways that matter when the consumer endpoint goes down for an hour or the platform itself has an incident. This is a deep look at the three webhook surfaces, the failure modes that bite in production, and the DLQ pattern that keeps a Shopify Plus order pipeline correct under real conditions.

Headline Comparison

The three platforms occupy different points on the reliability tradeoff frontier. Shopify Plus and Stripe both run high quality, well-tested webhook fleets with retry windows long enough that a brief endpoint outage rarely loses an event. NetSuite's webhook surface is fundamentally different: SuiteScript user event scripts and scheduled scripts emit "webhooks" in the sense of outbound HTTP POSTs, but the platform does not guarantee delivery the way Shopify or Stripe does, and the retry behavior depends on the script the team wrote. The integration pattern that ships in production has to treat NetSuite as the least reliable of the three and pull the missing events on a schedule, rather than waiting for the push.

Shopify Plus Webhooks in Practice

Shopify Plus retries failed webhook deliveries up to 19 times over 48 hours with exponential backoff. The first retry fires roughly 60 seconds after the failure, and the gap doubles up to a maximum of 24 hours between attempts. The consumer endpoint can fail (4xx or 5xx response, or no response within the 5 second timeout) for the entire 48 hour window and the event will still land, which is enough to absorb most realistic endpoint outages.

The two failure modes that bite in production on Shopify Plus are duplicate deliveries and reordered deliveries. A retry may fire even after the original delivery succeeded if the response was delayed past the 5 second timeout, which means the consumer endpoint will see the same logical event twice. The X-Shopify-Webhook-Id header is unique per delivery, not per logical event, so the idempotency key has to be derived from the event payload (typically order id plus event type plus updated_at timestamp), not the header value.

// Idempotency key derivation for Shopify webhooks
function shopifyIdempotencyKey(topic: string, payload: ShopifyPayload): string {
  switch (topic) {
    case "orders/updated":
    case "orders/paid":
    case "orders/cancelled":
      return `shopify:${topic}:${payload.id}:${payload.updated_at}`;
    case "inventory_levels/update":
      return `shopify:${topic}:${payload.inventory_item_id}:${payload.location_id}:${payload.updated_at}`;
    default:
      // The X-Shopify-Webhook-Id header is unique per delivery, useful for audit
      // but not as the logical idempotency key.
      throw new Error(`Unknown topic ${topic}, define an idempotency key shape`);
  }
}

The reordering case is more subtle. Shopify delivers webhook events independently per topic per shop, with no strict ordering. The orders/updated event can arrive before the orders/create event if the create webhook hit a transient retry path. The consumer logic has to be tolerant of out of order arrival by storing the last seen updated_at per record and ignoring events older than what is already persisted.

Stripe Webhooks in Practice

Stripe runs the highest reliability webhook fleet of the three platforms. The retry policy extends up to 3 days with exponential backoff, the event id is stable across retries (so the idempotency check is a single field comparison), and the Stripe Dashboard surfaces every delivery attempt with full request and response bodies for the last 30 days.

The two failure modes worth attending to on Stripe are missed events when the endpoint URL changes and stale signatures. Endpoint rotation (moving from one URL to another during a migration) requires explicitly disabling the old endpoint after the new one is wired up; leaving both active doubles the per-event delivery cost without functional benefit. Stale signatures occur when the signing secret rotates and the consumer keeps the old secret; the platform will continue to deliver and the consumer will reject every delivery as invalid until the secret is updated.

// Stripe signature verification with replay protection
import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

export function verifyStripeWebhook(req: Request): Stripe.Event {
  const signature = req.headers["stripe-signature"];
  const body = req.rawBody;
  // tolerance defaults to 300 seconds (5 minute replay window)
  return stripe.webhooks.constructEvent(
    body,
    signature,
    process.env.STRIPE_WEBHOOK_SECRET!,
  );
}

The Stripe webhook reliability is high enough that a well-built consumer endpoint can treat the push events as authoritative for payment state. The migration tradeoffs between Stripe and Shopify Payments for headless storefronts are covered in our Stripe vs Shopify Payments analysis; on the webhook reliability axis, the two are comparable in 2026.

NetSuite Webhooks in Practice (and Why You Need a Puller)

NetSuite's webhook story is the weakest of the three platforms, and the integration pattern that ships in production reflects it. The platform does not have a first class webhook product. Outbound notifications come from SuiteScript user event scripts (triggered on record save) or scheduled scripts (running on a cron schedule), both of which call back to the consumer endpoint via N/https module calls. The delivery reliability depends entirely on the script the engineering team wrote.

The standard failure modes on NetSuite are well known to anyone who has integrated the platform at scale. A user event script that runs synchronously on record save will fail the record save if the consumer endpoint is slow or unreachable, which is an unacceptable production behavior. A user event script that runs asynchronously (deferred via NetSuite's queue) will retry on failure, but the retry budget is shared across all scripts in the account and exhausts faster than the team expects under load. A scheduled script that polls for changed records is more reliable but introduces latency of one to several minutes between the record change and the consumer notification.

The integration pattern we ship in production for NetSuite combines a thin push notification (user event script that fires a fire and forget HTTPS POST with the record id and event type, no payload) with a puller process on the consumer side that calls the NetSuite REST API on a schedule to fetch the full record. The push is a cache invalidation, not a source of truth. The puller is the source of truth, and the puller's idempotency on the consumer side handles both the missed push (the puller fetches the record on its next pass) and the duplicate push (the consumer's idempotency check rejects the second). This pattern is the only one we have shipped that survives the failure modes the platform actually produces, and the architecture lines up with the broader patterns covered in our NetSuite Shopify integration patterns guide.

// Puller pattern for NetSuite, runs every 60 seconds
async function pullNetSuiteChanges(since: Date): Promise<NetSuiteEvent[]> {
  const records = await netsuiteClient.search({
    type: "salesorder",
    filters: [["lastmodifieddate", "after", since.toISOString()]],
    columns: ["id", "lastmodifieddate", "status", "subtotal", "total"],
    limit: 1000,
  });

  return records.map(r => ({
    type: "salesorder.updated",
    record_id: r.id,
    idempotency_key: `netsuite:salesorder:${r.id}:${r.lastmodifieddate}`,
    payload: r,
  }));
}

The Dead Letter Queue Pattern That Holds the Pipeline Together

Across all three platforms, the consumer endpoint will at some point fail to process an event. The DLQ pattern that survives real production conditions has three layers: a fast path that processes the event in-line, a retry queue for transient failures, and a dead letter queue for events that fail repeatedly and need manual review.

The fast path's job is to return a 200 to the platform within the timeout window (5 seconds on Shopify, much longer on Stripe). Doing the actual processing in-line is a mistake; the consumer endpoint should validate the signature, enqueue the event for processing, and return 200. The actual processing runs in the worker pool on the retry queue, where the consumer can retry with backoff and full visibility into the failure mode.

The dead letter queue is the human in the loop. Events that fail the retry queue for 24 hours land in the DLQ with the full request body, the signature, the platform delivery id, and the error trace from each retry attempt. The on-call rotation reviews the DLQ daily and decides whether to replay, drop, or escalate each event. This is the layer that catches the unknown failure modes (a new event payload shape the consumer cannot parse, a schema migration that broke a downstream worker, an upstream platform that started emitting a new event type), and the absence of a DLQ in production is the most common root cause of "we lost an order" incidents.

When This Applies to Your Stack

A Shopify Plus storefront integrating Stripe for a secondary payment surface and NetSuite for ERP is the canonical fit for the patterns in this post. The webhook reliability gap between the three platforms means the integration cannot treat them uniformly; Shopify and Stripe push reliably enough to be treated as event sources, NetSuite requires a puller for correctness. The retry queue plus DLQ pattern is non-negotiable for a production deployment, and the idempotency key shape has to be derived from the event payload, not the platform's per-delivery headers.

If you are standing up a headless commerce backend on Shopify Plus with Stripe and NetSuite in the integration mix, Contra Collective has shipped this exact stack for enterprise brands at the order management, payment, and ERP layers. The webhook reliability patterns are one piece of a broader integration architecture that includes the data model, the failure recovery story, and the observability tooling. The integration pattern we ship is the one that survives the day the upstream platform has an incident, not the one that looks good on the architecture diagram. Our ERP integration patterns guide for Shopify Plus covers the broader architecture in detail.

FAQ

Can we use Shopify Flow instead of building our own webhook consumer? For low volume merchants and simple workflows (send an email when an order ships), Flow is fine. For a real headless commerce backend with NetSuite or another ERP in the mix, Flow does not have the reliability, the observability, or the idempotency surface to be the integration layer. Build the webhook consumer.

Do we need a separate DLQ per platform, or one DLQ for all three? One DLQ with platform tagged events. The DLQ schema is the same across all three (idempotency key, payload, error history, retry count), and consolidating the review surface makes the on-call rotation tractable. Per-platform DLQs are a premature optimization.

How do we handle webhook events during a downstream worker deployment? The retry queue absorbs the deployment window naturally. The consumer endpoint returns 200 to the platform, the events queue up in the retry queue, and the worker pool processes them as the new deployment comes online. The platform never sees the deployment, and no events are lost. Deployment windows over 5 minutes should be coordinated with the on-call to watch the retry queue depth.

What about Shopify EventBridge integration for AWS users? Shopify EventBridge is a viable alternative to direct webhooks for AWS-resident workloads. The reliability story is similar (Shopify guarantees delivery to EventBridge, AWS handles fan-out to Lambda or SQS), but the latency is higher (typically 1 to 5 seconds end to end) and the cost adds up at high event volumes. For most headless commerce backends, the direct webhook path is simpler and cheaper.