What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
A 200 OK confirms that a webhook sender received an HTTP response; it does not prove your application applied the event exactly once, in the right order, or at all. Reliable consumers verify signatures, acknowledge within the provider’s deadline, make side effects idempotent, and reconcile local state with the source system. Test those failure cases deliberately—not just the happy path.
What a successful webhook response does—and does not—prove
An acknowledgment is part of the delivery protocol, not a transaction receipt for every downstream effect. Your handler might return success before a background job fails, apply an event twice after a retry, or accept an older update after a newer one. A provider may also stop retrying while your local state remains incomplete.
As an Amazon Associate I earn from qualifying purchases.
Plan for three distinct questions: did your endpoint accept the delivery durably, did your application apply its effects safely, and does your local state still match the source system? A 2XX response alone answers only the sender-facing part.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsMake duplicate deliveries safe
Assume a delivery can be attempted again. The handler may finish its work but fail to return an acknowledgment in time; the sender may then retry. A redelivery may also be triggered manually. Design business operations so repeating an event does not repeat an irreversible effect.
Use idempotency at the business-effect boundary
Before applying an effect, check whether that effect has already been applied, using a durable record or an idempotent operation in the system that owns the effect. For example, record that an order update has been applied in the same database transaction as the corresponding state change where possible. A process-local cache is not a durable deduplication strategy: it disappears on restart and is not shared by multiple workers.
Distinguish delivery IDs from event IDs
Use the provider’s identifiers according to their meaning. GitHub documents that X-GitHub-Delivery identifies a delivery and retains the same value when that delivery is redelivered. Shopify recommends storing and checking X-Shopify-Webhook-Id when an operation is not idempotent; a duplicate should be skipped and acknowledged successfully. Shopify also documents that separate subscriptions for the same topic can have distinct webhook IDs but share an X-Shopify-Event-Id. In that case, the webhook ID identifies a delivery, while the event ID can correlate deliveries arising from the same merchant action. See GitHub’s webhook best practices and Shopify’s delivery verification guidance.
Do not treat these header names or semantics as universal. Check the documentation for the provider you integrate, and scope your deduplication key to the operation you need to protect.
Rank #2
Handle events that arrive out of order
Arrival order is not necessarily the order in which changes occurred. Shopify explicitly says, “As with other webhook systems, Shopify doesn’t guarantee ordering within a topic, or across different topics for the same resource.” Its documentation recommends using X-Shopify-Triggered-At or a payload’s updated_at timestamp to organize events. See Shopify’s webhook overview.
For a state-replacement update, compare a trustworthy event timestamp or version with the state already stored, and avoid letting an older update overwrite a newer one. For events that represent actions rather than snapshots—such as separate increments or transitions—a timestamp comparison alone may not be enough. Apply application-specific state checks, or retrieve current state from the source system when that is the safer way to resolve ambiguity. Treat timestamps as provider- and payload-specific data, not as a universal ordering guarantee.
Verify signatures before trusting the payload
Authentication must happen before you act on webhook contents. Shopify’s HTTPS deliveries include a base64-encoded HMAC in X-Shopify-Hmac-SHA256, calculated with the app client secret and the raw request body. Capture the raw bytes before JSON body parsing changes the representation, calculate the expected signature, and compare it using a constant-time comparison where your platform provides one. Reject a missing or invalid signature before queuing or processing the payload. Shopify warns not to trust payload contents before HMAC verification; see its verification instructions.
Signature formats and signed request representations vary by provider. Follow the relevant provider’s instructions rather than assuming Shopify’s header, algorithm, or raw-body rule applies everywhere. GitHub recommends HTTPS with SSL verification and a high-entropy webhook secret in its webhook best practices.
Acknowledge within the provider’s deadline
Keep the request path short enough to meet the provider’s documented response limit. If meaningful work may take longer, verify the request, durably record or enqueue it, and acknowledge only after that acceptance step succeeds. A background queue separates delivery handling from slower business processing, but it does not remove the need to monitor failed jobs, preserve work across restarts, and make retries safe.
GitHub’s documented limit
GitHub says, “Your server should respond with a 2XX response within 10 seconds of receiving a webhook delivery.” If the endpoint takes longer, GitHub terminates the connection and treats the delivery as failed. GitHub suggests a queue for asynchronous processing. These are GitHub-specific instructions, not a general timeout standard. Source: GitHub Docs.
Shopify’s documented limits and retries
Shopify’s delivery-verification documentation specifies a one-second connection timeout and a five-second timeout for the full request. It expects 200 OK; a response outside the 200 range, including a redirect, is treated as an error. If Shopify receives no response or an error, it retries eight times over the next four hours. After eight consecutive failures, a subscription configured through the Admin API is automatically deleted. These figures and consequences are Shopify-specific and may change; consult the current delivery-verification documentation for the integration you operate.
Retries are not a recovery plan
Retries can help with temporary failures, but they cannot guarantee that every event will reach your application or that a delivery will be retried indefinitely. Shopify states, “Your app shouldn’t rely on receiving data from Shopify webhooks.” It recommends periodic API reconciliation so local data can be compared with Shopify’s source data. See Shopify’s webhook overview.
Build a reconciliation job around the records and state your application depends on: query the source system periodically, compare its current state with yours, and repair missing or stale records. Also establish a recovery procedure for provider-supported redelivery after an outage. GitHub recommends redelivering missed deliveries once your server recovers; see GitHub’s best practices. Redelivery can help restore individual events, while reconciliation checks whether the resulting state is actually complete.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to test duplicates, disorder, and retries locally
This is a recommended test matrix synthesized from the documented failure modes, not a provider-certified or standardized suite. Use the provider’s actual signature scheme and retry behavior in integration tests; local simulations should not be mistaken for proof of production delivery semantics.
| Test | What to simulate | What to verify |
|---|---|---|
| Sequential duplicate | Submit the same signed delivery twice, one after the other. | The business effect occurs once, and the duplicate is handled without creating a second effect. |
| Concurrent duplicate | Submit the same delivery simultaneously to multiple workers. | Durable deduplication or an idempotent operation prevents a race from applying the effect twice. |
| Signature and tampering | Send a validly signed body, then change the body without updating its signature; also try a missing or invalid signature. | Verification uses the required request representation, accepts the valid request, and rejects altered or unauthenticated input before processing. |
| Slow handler and timeout | Delay downstream work until the provider-facing request would exceed its documented deadline. | The request path durably accepts work and responds within the actual provider’s limit; background failure remains observable and recoverable. |
| Reverse-order updates | Deliver two updates for the same resource in reverse chronological order. | Stale data does not overwrite newer state under your timestamp, version, state-check, or fetch-current-state policy. |
| Temporary failure and recovery | Return an error or fail to respond temporarily, then restore service. | You understand the provider’s retry and redelivery behavior, and repeated attempts do not repeat business effects. |
| Outage beyond retries | Simulate an outage long enough that provider retries are exhausted. | Reconciliation finds and repairs missing records or updates, and any available manual redelivery path is understood. |
Instrument the path from receipt to repair
Log and measure the delivery ID, event ID where the provider supplies one, signature result, acknowledgment latency, queue status, processing attempts, and reconciliation outcome. These are useful implementation choices, not requirements imposed by the cited provider documents. They make it possible to distinguish a rejected request from an accepted delivery that later failed in a worker.
Choose an ingress design that matches your recovery needs
You can receive webhooks directly and operate your own durable queue, or use managed ingress or delivery infrastructure. Neither approach is a universal winner; compare the capabilities you need and verify current terms before adopting a service.
Quick Recap
Build and operate the receiver and queue
- You control persistence, processing rules, and how delivery records connect to application state.
- You also own queue operations, delivery visibility, recovery and replay mechanisms, and fan-out to downstream services.
- This can fit an existing platform with operational capacity for durable ingestion and monitoring.
Use managed ingress or delivery infrastructure
- Evaluate provider coverage, signature verification, durable storage, retry and replay behavior, filtering, transformations, fan-out, and operational fit.
- GitHub names Hookdeck as an example of a service for asynchronous queueing in its best practices. Svix describes an ingress service that verifies, stores, filters, transforms, and fans out events with retries in its service materials.
- Verify the current feature set, price, and terms directly before choosing; these descriptions do not establish comparative performance or a recommendation.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
