Behind almost every Shopify automation, from posting orders to a team channel to updating a warehouse, sits a webhook. Store owners rarely see them, yet they decide whether automations are fast, reliable and safe. When a flow runs twice, or an order never reaches a supplier, or a tool works for months and then quietly stops, the cause is very often something about how webhooks are delivered and handled. Understanding the basics lets you ask better questions of whoever builds your automations, and spot a design that will fail.
This guide explains webhooks without code. It describes what they are, how Shopify delivers them, what Shopify promises and what it does not, and the patterns that make automations robust. The delivery details here were read from Shopify’s developer documentation on 20 October 2026; the platform changes over time, so always check the current pages. If you are choosing the tool that receives the events, see Zapier vs Make vs n8n for Shopify stores, and for why events matter to stock, inventory sync across sales channels.
What a webhook is
There are two ways for one system to learn what another has done. It can ask repeatedly: has anything changed? That is polling, and it is slow and wasteful. Or the other system can tell it as soon as something happens. That is a webhook. In Shopify, you register an address for a topic, such as orders being created or inventory changing, and from then on Shopify sends a message to that address each time the event occurs. The message contains the details of the event, such as the order.
| Polling | Webhook | |
|---|---|---|
| Who starts it | Your system asks on a timer | Shopify sends when it happens |
| Speed | Delay up to the timer interval | Near real time |
| Cost | Many empty requests | One message per event |
| Risk | Misses nothing, but slow | Can be duplicated, delayed or missed |
| Best use | Reconciliation and catching up | Reacting quickly |
The rules of delivery
Shopify’s documentation sets out a few specific expectations that every receiver must meet. These are the points that explain most real-world problems.
| Rule | What Shopify says | Why it matters |
|---|---|---|
| Reply quickly with success | Acknowledge with a 200 response. Shopify allows a one-second connection timeout and five seconds for the whole request | Slow work inside the receiver causes failures and retries |
| Any non-success reply is an error | Responses outside the 200 range, including redirects, count as failures | A misconfigured address that redirects will fail every time |
| Retries | If there is no response or an error, Shopify retries 8 times over the next 4 hours | A brief outage is survived; a long one is not |
| Subscription removal | After 8 consecutive failures, subscriptions created through the Admin API are automatically deleted, with warning emails to the app’s contact | An outage can silently end your automation |
| Duplicates | Shopify minimises them, but the same webhook can still arrive more than once | Every action must be safe to run twice |
| Identification | Each delivery has a webhook ID header; deliveries from one merchant action share an event ID | You can detect repeats and related deliveries |
| Signature | A signature header, generated from the raw body and the app secret, lets you verify the sender | Without checking it, anyone could send fake events |
Shopify’s documentation also suggests queuing payloads for asynchronous processing so that bursts do not cause timeouts, and it recommends a reconciliation job that uses the APIs to fetch missed data as a common safeguard. Both are the heart of a robust design.
Common topics and what they are used for
| Topic (typical) | When it fires | Typical automation |
|---|---|---|
| Order created or paid | A customer places or pays for an order | Tag, route, notify, post to accounting |
| Order updated or cancelled | An order changes | Update a supplier or the warehouse |
| Fulfilment created or updated | A shipment is created or its tracking changes | Send shipping messages |
| Refund created | A refund is issued | Notify support, update books, restock |
| Inventory level updated | Stock changes | Sync to other channels, alert on low stock |
| Product created or updated | A product changes | Sync to feeds and marketplaces |
| Customer created or updated | A customer changes | Update email platform and CRM |
| App uninstalled | An app is removed | Clean up data and stop calling |
Topic names and payloads differ by API version. Check the current list in Shopify’s documentation.
What can go wrong, and what it looks like
- The same event arrives twice. The automation tags an order twice, emails twice or creates two supplier orders.
- An event never arrives. An order is missing from the warehouse. Causes include an outage during all retries, a deleted subscription or an unreachable address.
- Events arrive out of order. An order-updated event can arrive before the order-created event. A receiver that assumes order breaks.
- The receiver is too slow. It does heavy work before replying, so Shopify sees a timeout and retries, causing duplicates.
- The subscription disappears. After repeated failures it is removed, and nothing arrives until someone notices.
- Fake events. A receiver that does not check the signature accepts forged requests.
The patterns that make it safe
Verify, acknowledge, queue
On arrival, a good receiver checks the signature against the raw body, replies with success at once and puts the event on a queue. A separate worker processes the queue at its own pace. This keeps replies inside the five-second window, absorbs bursts and lets failed work retry without involving Shopify.
Make every action idempotent
Idempotent means doing it twice has the same effect as doing it once. Record each webhook ID after processing, and skip any repeat. For actions that create something, such as a supplier order, use a key built from the order ID, so that a second attempt finds the first and stops. Without this, retries and duplicates create real-world duplicates.
Do not trust the order
Design for events arriving in any order. If an update arrives for an order you have not seen, fetch the order from the API or hold the update until the creation arrives. Use timestamps or version numbers from the payload to ignore stale updates.
Reconcile on a schedule
Because webhooks can be missed, run a job, hourly or daily depending on the stakes, that asks the API for recent orders or changes and compares them with what you processed. Anything missing is processed now. This catch-up job is also how you recover after your own outage. Our order automation rules and the stock design in inventory sync both depend on it.
Alert on silence
A webhook that stops arriving produces no error, so nothing tells you. Add a check that alerts when no events of an expected kind have arrived for a time that is longer than usual, for example no orders in three hours on a normally busy store. Also check regularly that your subscriptions still exist.
Security basics for store owners
- Always verify the signature. If your tool offers a setting for it, switch it on, and ask your builder how it is checked.
- Keep the app secret private. It is used to sign messages; treat it like a password and keep it out of chat and shared documents.
- Use HTTPS addresses you control. The endpoint should be under your control, with up-to-date software.
- Log carefully. Webhook bodies contain customer data, so keep logs short-lived and access-controlled.
- Limit what the receiver can do. Grant only the permissions the automation needs.
Webhooks in no-code tools
Tools such as Zapier, Make and n8n can receive Shopify events for you, so you may never write a receiver. They handle the signature and the quick reply in many cases, but the other responsibilities remain yours: duplicate protection, ordering and reconciliation. A workflow that adds a row to a sheet for every order event will add two rows when an event arrives twice, unless you add a step that checks the order ID. Ask of every workflow: what happens if this event arrives twice, late or not at all?
| Question | Good answer |
|---|---|
| What if the event arrives twice? | The action checks a key and does nothing the second time |
| What if it arrives late or out of order? | The workflow fetches current data or ignores stale updates |
| What if it never arrives? | A reconciliation job finds the missing order and processes it |
| What if my tool is down for a day? | Catch-up reads everything since the last success |
| How would I know it stopped? | An alert on silence and a weekly check of subscriptions |
A worked example
A store posts each order to a supplier through a workflow triggered by an order webhook. One afternoon the supplier’s system slows, the workflow takes eight seconds to reply and Shopify records a timeout. It retries, and when the supplier recovers, the workflow receives the same order twice and creates two supplier orders. The customer receives two parcels, and the store pays twice. The fix is not a faster supplier but a better design: reply immediately, queue the work and key each supplier order on the Shopify order ID so that the second attempt finds the first. Add a daily comparison of Shopify orders with supplier orders to catch anything else. That is the kind of design our order routing to suppliers service builds, and the wider workflow design lives in ecommerce workflow automation.
Sources and further reading
Figures and rules in this guide come from the primary pages below. Platform limits and prices change, so open the page before you build on a number.
- Shopify developer docs: HTTPS webhook subscriptions, response time, retries, headers, duplicates and removal, read 20 October 2026
- Shopify developer docs: webhooks overview, topics and delivery methods
- Shopify developer docs: rate limits, leaky bucket model and backoff guidance