Build1 publisher2 min readPublished
Hand-built Shopify webhooks lose their subscription without notice when the receiver fails
Shopify removes the subscription from a webhook whose destination is failing, and it emails the owner only when an App Store or custom app created the webhook. A merchant who builds one by hand in the admin has to watch the receiver themselves.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Shopify lets a merchant edit a webhook after creating it, except for the event it fires on.
- Events leave a store by one of three routes: an admin webhook, Shopify Flow's Send HTTP request action, or an app that registers its own subscription.
- Flow's Send HTTP request is available only on the Grow, Advanced and Plus plans, so entry-tier stores get the admin webhook and installed apps.
- Zapier labels each Shopify trigger Instant or Polling, while other connector listings do not say whether they register a subscription or poll.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- exposure A partner fed by a hand-built webhook can stop receiving records with no alert to the merchant, so the first sign of a lost subscription is missing data at the receiving end.
- decision The event choice is final for that webhook; sending a different event later means creating a second webhook for the receiver to handle.
- constraint Entry-tier stores that need an event filtered before it leaves must filter at the receiver or inside an installed app, since Flow's HTTP action is unavailable to them.
The admin form is the easy part. It asks for four things: the event, the format, the destination URL and the webhook API version. Then it offers a Send test button [3]. The event comes from a closed menu of 17 categories, Cart through Transaction [8]. I think the form suits the person who usually fills it in, a merchant pasting an address a vendor sent over. It refuses five kinds of destination, including localhost, any URL ending in "internal", custom domains attached to the store and Shopify's own domains [10].
Once saved, a webhook is an outbound instruction. When the event fires, Shopify posts the record as JSON or XML to the HTTPS address, and nothing polls [9]. According to the dev.to write-up, Send test answers one narrow question: did a sample reach the address [11]. A passing test covers one delivery. Shopify's developer docs are frank about the rest: "Webhook delivery isn't always guaranteed, and your app can miss or mishandle events for other reasons, such as handler failures or downtime." [7]
Receiver downtime costs more than missed events. A failing destination loses its subscription [5]. The write-up does not disclose how many failed deliveries, or how long an outage, triggers the removal.
The write-up's answer for hand-built webhooks is a recurring check in the calendar [14]. For a merchant on the admin route, that calendar reminder is the only check on the receiver [1].
The write-up says connectors are a real route, and the one merchants misread. Zapier and Make ship official App Store listings, and n8n documents a Shopify Trigger node [12]. Polling adds delay the merchant cannot see [15]. The failure email for app-created webhooks also reaches the merchant only if the connector actually created a webhook [16]. A connector that polls is outside that alert entirely. The write-up advises asking the vendor which method it uses, then pricing webhook against poll [17].
What to watch
- Shopify publishing how many failed deliveries, or how long an outage, it takes before a webhook subscription is removed.
- Shopify extending the lost-subscription email to webhooks merchants create themselves in Settings > Notifications.
- Make, n8n and other connector vendors labelling their Shopify triggers as instant or polling, as Zapier already does.