If you wire Shopify events into your own endpoint, a queue or a no-code tool, the interesting decisions are not in the admin form. They are in which route carries the event, what happens when your receiver starts failing, and which failures nobody tells you about. This write-up compares the three routes out of a store, walks through the four-field admin webhook, and lists what Shopify documents (and does not) about delivery and silent deletion.
The original article has an interactive setup checklist; here it is a plain list.
The quick verdict
Let the other side decide your route: a plain HTTPS address means an admin webhook, a need to filter the event first means Shopify Flow on Grow, Advanced or Plus, and a vendor with its own App Store listing means installing the app.
| Situation | Answer | Why |
|---|---|---|
| A vendor handed you an HTTPS address | Create it in the admin | Four fields in Settings > Notifications > Webhooks, on a page naming no plan requirement (read September 18, 2026) |
| The event must be filtered before it leaves | Shopify Flow, Send HTTP request | Flow puts conditions and stored secrets in front of the call, on Grow, Advanced and Plus only |
| You need filtering on an entry tier | A connector or app, filtering on their side | Flow's action is out of reach below Grow; a connector applies the vendor's own filters |
| The destination has its own App Store listing | Install the app instead | Shopify emails the owner about a failed webhook only when an App Store or custom app created it — ask the vendor to confirm its connector does |
If a vendor handed you an HTTPS address, create the webhook yourself in Settings > Notifications > Webhooks: four fields, no code. If the event must be filtered before it leaves, use Shopify Flow's Send HTTP request, which is available only on the Grow, Advanced and Plus plans.
You cannot change the event once the webhook exists, and a failing destination loses its subscription. Shopify emails the owner about that only when an App Store app or a custom app created the webhook, so put a recurring check in your calendar.
What a webhook sends, and to whom
A Shopify webhook is an outbound message: when the event you picked happens in your store, Shopify sends that record to an HTTPS address you typed in, as JSON or XML. Nothing polls and nobody signs in — the data arrives at whoever owns that address.
Someone asks you to add a webhook — a fulfilment partner, an accountant, a SaaS vendor. What they want is a standing instruction in your admin: when the chosen event fires, Shopify posts the record to their server. The event comes from a closed menu, not a free-text field.
The seventeen event categories in the Event menu: Cart, Checkout, Collection, Customer, Discount, Draft order, Fulfillment, Inventory, Location, Market, Order, Product, Refund, Shop, Tender, Theme and Transaction — the Supported webhook events section of Shopify's Creating webhooks page, read September 18, 2026.
What you get is an attempt at delivery, not a guarantee, and Shopify says so itself:
"Webhook delivery isn't always guaranteed, and your app can miss or mishandle events for other reasons, such as handler failures or downtime." — Shopify, Webhooks — Shopify Dev Docs
Admin webhook, Flow or a connector: pick the route first
Three routes carry an event out of a Shopify store: a webhook you create in Settings > Notifications, Shopify Flow's Send HTTP request on Grow, Advanced and Plus, or an app that registers its own. Pick by what the other side gave you.
The route decides who sets it up, whether the event is filtered first, and who hears when it breaks. Flow's Send HTTP request action is only available to the Shopify Plus, Advanced, or Grow plans, so the entry tier leaves you the admin webhook and installed apps.
| Route | Where it is created | Plan boundary | Conditions first? | Failure email | What Shopify documents about delivery |
|---|---|---|---|---|---|
| Admin webhook | Settings > Notifications > Webhooks | None on the page documenting it | No | No one | Repeated non-200 replies delete the subscription automatically |
| Shopify Flow, Send HTTP request | Inside a workflow | Grow, Advanced, Plus | Yes, plus stored secrets | A workflow action, not a subscription | Waits up to 30 seconds for a response code; on 4XX, 5XX or 429 you pick Retry for up to 24 hours, Fail or Ignore |
| App or connector | Inside the app | Whatever the vendor sets | Vendor's own | The store owner, when an App Store or custom app created it | Not named on the listings; Zapier's own page marks each trigger Instant or Polling |
Source: Shopify Help Center and Shopify Dev Docs, read September 18, 2026.
The third row is the one merchants misread. Zapier and Make ship official App Store listings, and n8n documents a Shopify Trigger node, so a connector is a real route.
The listings do not say how the connector learns your event happened — by registering a subscription in your store, or by polling on a schedule. Zapier's own integration page does label each Shopify trigger Instant or Polling; for the others, ask the vendor, because the answer matters twice: polling adds delay you cannot see, and the failure email for app-created webhooks reaches you only if the connector created one. Then price webhook against poll.
How do you create a webhook in Shopify?
From your Shopify admin go to Settings > Notifications, click Webhooks, then Create webhook, and fill four fields: the event, the format, the destination URL and the webhook API version. Save it, then use Send test and verify at the URL that the data arrived.
None of the four is cosmetic: Shopify lets you edit a webhook after it is created but never its event, and the receiver depends on all four.
| Field | What you choose | What it commits you to |
|---|---|---|
| Event | One of 17 categories | Shopify states you cannot change it later — switching means deleting this subscription and building another |
| Format | JSON or XML | The receiver has to parse what you picked; Shopify's webhook API resource lists JSON as the default |
| URL | The HTTPS address for the data | Everything the event carries leaves your store for it, and five kinds of address are refused |
| Webhook API version | A quarterly version | The payload follows that version, and each stable version is supported for at least 12 months |
Source: Creating webhooks, Shopify Help Center, read September 18, 2026.
Five kinds of address Shopify refuses:
- Localhost.
- Any URL ending in the word "internal", such as example.com/internal.
- Any URL from a custom domain attached to the store.
- "Fake" domains, such as www.example.com.
- Shopify domains, such as shopify.com and myshopify.com.
Send test answers one narrow question: did a sample reach the address. Shopify's steps end with checking that at the URL itself and say nothing about the receiver keeping it, so confirm that before you call the integration live.
The signature your receiver checks
Anyone who learns your address can post to it, so the receiver should verify a delivery really came from your store: Shopify signs webhooks with an ID unique to your shop, while the HMAC check in its developer documentation is written for apps and uses the app's client secret. Neither page gives a verification recipe for a webhook created in the admin, so ask whoever builds the endpoint how they will confirm a delivery came from your store.
The API version you pick has an expiry
The Webhook API version is not permanent scenery. Shopify releases a new version every three months and supports each stable one for at least twelve months, payloads follow the version you chose, and individual event topics can be dropped from later versions.
Shopify releases a new API version every three months, on the first day of the quarter, and supports each stable version for at least twelve months, with at least nine months of overlap, per its own versioning documentation.
When the version you picked becomes inaccessible, Shopify falls forward — its versioning page says so for webhooks specifically — and webhooks include an X-Shopify-Api-Version header to confirm which version was used. The page does not name the admin field, so treat this as the general rule and have the receiver read that header.
Topics themselves disappear. Shopify removed the checkout_and_accounts_configurations/update webhook on January 1, 2026, announced in a changelog post the previous August — so a webhook set and forgotten deserves a look.
When delivery fails: deleted without an email
A destination that repeatedly answers with anything other than 200 loses its subscription, and Shopify deletes it from the admin automatically. The failure email goes to the store owner only for webhooks an App Store or custom app created, so one you made stops silently.
Shopify's page documents no banner, alert or log for a deleted subscription: it is gone from Settings > Notifications, and the orders that reached your accountant stop reaching them. There is a guide to finding the delivery log route by route that starts there.
"If the webhook destination repeatedly returns a non-200 status response, then the webhook subscription is automatically deleted from your Shopify admin." — Shopify, Creating webhooks — Shopify Help Center
Whether an email reaches you depends on who created the webhook, not on how badly it failed: Shopify sends one only when an App Store app or a custom app created the subscription.
Shopify publishes those delivery numbers only on a page addressed to apps, and no page we have found extends them to a webhook created in Settings > Notifications.
So the defence is a habit, not a number. Compare what reached the other side with what Shopify recorded, on a schedule — the reconciliation loop behind any custom ERP integration.
What we looked for and did not find: every absence here rests on one reading, done September 18, 2026 — Shopify's Creating webhooks page, its Send HTTP request reference, the developer pages on building and troubleshooting webhooks, the Admin API webhook resource, the API versioning page, the Zapier and Make App Store listings, and n8n's Shopify Trigger documentation.
Customer data on someone else's URL
The payload is the record, not a notification: a customer or order event carries the name, email, phone and full address. Once it reaches the URL you typed, another party holds it, and the pages we read do not extend Shopify's protected customer data rules to a webhook a merchant creates.
Shopify's sample payload for a new customer lists first and last name, email, phone, currency and the full default address — the record itself, not a ping saying a customer was created. The sample for a new order carries the same customer name, email and phone, plus the billing and shipping addresses.
The approval regime that covers apps does not obviously cover you: those requirements are written for apps and the Admin API, and no page we have found addresses a webhook a merchant creates.
So the checks before you save that address are yours:
- Who holds the data once it lands.
- Whether the address is access-controlled, not a catch-all.
- What your privacy policy promises about sharing.
- How you switch it off, which is deleting the subscription.
Erasure is the other half: when a customer asks you to delete their data, the copy on someone else's server is yours to chase, and Shopify's side of it stops at tools and notices.
Set it up so you notice when it dies
Shopify's page names nothing that tells you a webhook died, so build the telling into your own routine: agree the event and address first, test after you create it, write down what you made, and re-open the list on a schedule. Only the last step repeats.
Step one happens before you touch the admin, two and three on the day you create the webhook, and the last two keep it from disappearing unnoticed.
-
Settle the event, the format and the address. Get the event, the format and the exact HTTPS address in writing, then check the address against the blocked list above.
- The event name is written down, not described.
- The address is none of the five blocked kinds.
- You can name who holds the data there, and your policy covers it.
-
Create the webhook and save it. In Settings > Notifications > Webhooks, click Create webhook and fill the four fields.
- The event is the one you agreed, since it cannot change later.
- The API version is the one the receiver was built against.
-
Send a test, then confirm it was stored. Send test sends a sample to the address; confirm on the receiving side that it arrived and was kept.
- The test was sent from the admin.
- Someone confirmed the record arrived and was saved.
-
Write down what you created. Record the event, address, API version and date, because a subscription created here is not returned in API calls.
- Those four details live outside Shopify.
- The receiving side holds the same record.
-
Put a recurring check in your calendar. Re-open the Webhooks list on a schedule and confirm the subscription is still listed, because a failing one goes without an email.
- A repeating reminder exists.
- You know what the list should contain.
The bottom line
Creating a Shopify webhook is four fields in the admin, and the hard part is everything around it: the route the other side forces on you, the event you cannot change later, the customer data that leaves with every delivery, and the deletion nobody emails you about.
Shopify gives merchants a code-free way to push events out of a store, then documents the limits honestly: delivery is not guaranteed, a failing destination loses its subscription, and the email is reserved for app-created webhooks.
Create it yourself, but never leave it unwatched. An address you were handed means the admin route and four fields; an event that needs filtering first means Flow, on Grow, Advanced or Plus. Either way, put a recurring check in the calendar — Shopify's page documents no alert for a deleted webhook.
Frequently asked questions
Do I need a developer to create a webhook in Shopify?
Not to create one. From your Shopify admin you go to Settings > Notifications, click Webhooks, then Create webhook, and fill four fields: the event, the format, the destination URL and the webhook API version. The developer work sits on the other end, where somebody has to run the address that receives the data and confirm each delivery really came from your store.
Which Shopify plan do I need for webhooks?
The Help Center page documenting Settings > Notifications > Webhooks walks through the whole procedure without naming a plan requirement, read on September 18, 2026. What does carry a plan boundary is Shopify Flow's Send HTTP request action, which Shopify states is available only to the Shopify Plus, Advanced and Grow plans.
Why did my webhook disappear from Settings, Notifications?
Because the destination kept failing. Shopify states that if the webhook destination repeatedly returns a non-200 status response, the subscription is automatically deleted from your admin. Nothing is restored for you. Once the receiving address answers correctly again, you create the webhook a second time and send a test before trusting it.
Can I change the event after the webhook is created?
No. Shopify's page states plainly that you cannot change the webhook event after the webhook is created. Moving from order creation to order fulfilment, for example, means deleting that subscription and creating another one with the new event, the same address and the same API version. Warn the receiving side before you do it.
Does Shopify email me when a webhook stops working?
Only for some webhooks. Shopify sends an email to the store owner's address when a webhook fails, and states that the email is sent only when the webhook was created by an app from the Shopify App Store or by a custom app. One you created yourself in Settings > Notifications falls outside that.
JSON or XML: does the choice matter?
It matters to whoever receives the data rather than to your store. The Format menu offers exactly two choices, JSON or XML, and Shopify's webhook API resource page lists JSON as the default value. Ask the receiving side which one its endpoint parses, because changing your mind later means editing the webhook again.
What does the Webhook API version field actually do?
It fixes the shape of the data you receive. Shopify versions webhook payloads the same way as API responses, releases a new version every three months, and supports each stable version for a minimum of 12 months with at least nine months of overlap. Pick the version the receiving side was built against.
Is Shopify Flow's Send HTTP request the same thing as a webhook?
No. It is an action inside a Flow workflow rather than a subscription in Settings > Notifications, so you can put conditions in front of it and keep secrets in Flow settings. Flow waits a maximum of 30 seconds for a response code, and on an error you choose Retry for up to 24 hours, Fail or Ignore.
Will webhooks created by an app show up in the same list?
Shopify documents only the opposite direction: a subscription you create through the admin is not returned in API calls, because it belongs to the shop rather than to an app. No page we have found states whether the admin list shows app-created subscriptions, so treat that list as the record of what you made there.
How do I test a webhook before I rely on it?
Use Send test. Shopify describes it as a way to check that the event information you want is being sent to the correct URL, and its steps end with verifying at that URL that the notification works. A received test proves the address is reachable, not that anything was kept, so confirm on the receiving side that the record actually arrived.
Originally published at shopify.ecom-store.pro.
Disclosure: this article is AI-generated.
Top comments (0)