Webhook

Why it matters

Webhooks are what make an integration feel immediate rather than eventually correct. Without them, external systems poll — asking every few minutes whether anything changed — which wastes API quota, adds latency proportional to the polling interval, and scales badly as the number of connected systems grows.

With them, the warehouse learns about an order the moment it is paid, the accounting system sees the refund as it happens, and the ERP updates without a schedule.

The catch is the delivery guarantee, and it is the source of most webhook bugs. Shopify delivers at least once, not exactly once, and not necessarily in order. An integration written on the assumption that each event arrives once, in sequence, will work in testing and produce duplicate orders in production.

How it works on Shopify

You subscribe to a topic — orders/paid, products/update, inventory_levels/update — and provide an endpoint. Shopify posts the payload there when the event occurs.

Every request carries an HMAC signature. Verifying it is not optional: without verification, the endpoint accepts fabricated orders from anyone who discovers the URL.

Two properties make the handler correct. Idempotency: use the webhook ID or the resource's own identifier to recognise events already processed, because duplicates will arrive. And order-independence: an update event can reach you before the create event it logically follows, so handlers should reconcile state rather than assume a sequence.

Respond quickly. Shopify expects an acknowledgement within a short window and retries if it does not get one — so the handler should accept the payload, queue the work, and return. Doing the processing inline is how a slow downstream system turns into a retry storm.

Failed deliveries are retried over a period and then the subscription can be removed automatically, which is a silent failure worth monitoring for.

Shopify Flow can also call a webhook, which covers simple cases without building a subscription.

Common mistakes

• Not verifying HMAC. An open endpoint accepting anything that posts to it.
• Assuming exactly-once delivery. Duplicates arrive. Handlers must be idempotent.
• Assuming ordering. Update before create is normal and must not crash the handler.
• Processing inline. Slow handlers cause retries, which cause more load.
• No monitoring. Repeated failures can remove the subscription, and nothing announces it.
• Relying on them for reconciliation. Events can be missed. A periodic sync is the safety net.

When you need help

The trigger is duplicate or missing records — orders appearing twice in the ERP, fulfilments that never registered, inventory drifting without explanation. Those are handler correctness problems, and they are usually found by audit rather than by any single failing request.

The other case is designing the event model for a new integration: which topics to subscribe to, what is handled by webhook against scheduled sync, and how reconciliation catches what the events miss. That design is what decides whether the integration runs quietly for years or produces a weekly exception.