Shopify Webhooks: How to Use Them in Your Apps

If you've ever wondered why your inventory spreadsheet is always one step behind your actual stock levels, or why a customer's loyalty points don't update until you manually refresh a dashboard, the answer almost certainly comes down to how your store is listening — or failing to listen — to events as they happen. Shopify generates dozens of meaningful signals every single day: orders placed, products updated, customers created, fulfillments completed. Without a reliable mechanism to capture those signals in real time, every integration you build is essentially guessing. That guessing costs you time, money, and customer trust.

The traditional fix has been to poll Shopify's API on a schedule — checking every few minutes whether anything has changed. That approach is slow, burns through API rate limits, and still leaves gaps between checks where critical data can slip through. Webhooks solve this problem by reversing the relationship: instead of your app asking Shopify "has anything changed?", Shopify tells your app the moment something does. It's the difference between refreshing your inbox every ten minutes and having your phone ring when a new message arrives.

In this post, you'll learn exactly what Shopify webhooks are, how to configure and receive them, how to handle the most important event types for your store, and how to avoid the common mistakes that cause webhook pipelines to silently fail. Whether you're building a custom app, evaluating third-party tools, or trying to automate your post-purchase workflow, this guide gives you a practical foundation you can act on today.

What Are Shopify Webhooks and Why Do They Matter?

A webhook is an HTTP callback — a POST request that Shopify sends to a URL you specify whenever a particular event occurs in your store. When a customer completes checkout, Shopify immediately fires an orders/create webhook to your endpoint, delivering a JSON payload that contains the full order object: line items, customer details, shipping address, payment status, and more. Your server receives this payload, processes it, and responds with a 200 OK status to confirm receipt. The entire exchange typically happens within a few hundred milliseconds of the triggering event.

For merchants, the practical value is enormous. Consider a store doing 200 orders per day across two warehouses. Without webhooks, a fulfilment integration might poll the API every five minutes, meaning some orders sit unprocessed for up to five minutes before the warehouse management system even sees them. With webhooks, every order lands in the WMS within seconds of being placed. At 200 orders per day, that's up to 16 hours of accumulated delay eliminated daily — delay that directly affects shipping cut-off windows and customer satisfaction scores.

Webhooks also dramatically reduce API consumption. Polling an endpoint once per minute means 1,440 API calls per day whether or not anything has changed. A webhook-based approach might generate 200-300 calls on a busy trading day and near zero on a quiet one. For stores on Shopify's standard API rate limits, this headroom matters significantly when you're running multiple integrations simultaneously across inventory, CRM, and marketing platforms.

How to Register a Webhook in Shopify

You can register webhooks in three ways: through the Shopify Admin UI, via the REST Admin API, or using the GraphQL Admin API. For production apps, the API approach is almost always preferable because it's repeatable, version-controlled, and scriptable. Using the REST API, a simple POST request to /admin/api/2024-01/webhooks.json with a topic and address in the request body is all it takes to subscribe your endpoint to any supported event.

When registering via GraphQL — now the recommended approach for new development — you use the webhookSubscriptionCreate mutation. You pass the topic (for example, ORDERS_CREATE), the callback URL, and the format (JSON or XML, though JSON is standard). Shopify will immediately begin delivering events to that URL, so your endpoint must be live and returning 200 responses before you register. A common mistake is registering the webhook during development before the endpoint is actually deployed, which causes Shopify to begin counting failed delivery attempts against your subscription.

Shopify automatically disables webhook subscriptions after 19 consecutive failed delivery attempts. This means if your endpoint goes down for a weekend and Shopify can't reach it, you may return on Monday to find your subscription silently disabled and a backlog of events you've missed entirely. Building a registration check into your app's boot sequence — confirming that all required webhooks are still active on startup — is a defensive practice that saves significant debugging time in production.

Handling the Most Useful Webhook Topics for Merchants

Shopify exposes over 70 webhook topics, but for most merchants, a focused set of five or six covers the vast majority of practical use cases. orders/create is the workhorse: it fires the moment a customer completes checkout and is the entry point for fulfilment workflows, post-purchase email triggers, loyalty point attribution, and fraud screening integrations. orders/fulfilled fires when a fulfilment is completed and is the right moment to trigger shipping confirmation emails or update a third-party analytics platform with fulfilment velocity data.

inventory_levels/update is critical for any merchant managing stock across multiple locations or selling on multiple channels simultaneously. It fires whenever an inventory level changes at a specific location, giving you the data you need to push real-time stock figures to a marketplace listing or trigger a restock alert to your buying team. For a store supplying wholesale accounts alongside direct-to-consumer, this webhook is the backbone of any reliable oversell-prevention strategy.

customers/create and customers/update are the foundation of CRM integration. When a new customer is created — whether through a first purchase or an explicit account registration — this webhook gives you the trigger to add them to your email platform, assign them a customer segment, or kick off a welcome automation. Meanwhile, products/update is invaluable for content syndication: if you manage a catalogue across multiple storefronts or publish product data to a third-party comparison site, this topic ensures downstream systems stay in sync every time a price, title, or description changes.

Verifying Webhook Authenticity and Securing Your Endpoints

Every webhook Shopify sends includes an X-Shopify-Hmac-Sha256 header containing an HMAC signature generated using your app's shared secret. Verifying this signature before processing any webhook payload is not optional — it's a fundamental security requirement. Without verification, any actor who discovers your webhook URL can send fabricated order or customer data to your endpoint, potentially triggering fulfilment actions, loyalty credits, or data writes based on entirely fake events.

Verification is straightforward: compute an HMAC-SHA256 digest of the raw request body using your shared secret as the key, then base64-encode it and compare it to the value in the header. The critical detail most developers get wrong the first time is using the raw, unparsed body for the computation. If you parse the JSON into an object and re-serialize it before hashing, the byte-for-byte representation may differ and your HMAC will never match, causing you to reject every legitimate webhook Shopify sends you.

Beyond HMAC verification, apply standard endpoint hardening: use HTTPS only, reject any request that arrives over plain HTTP, set a reasonable request timeout (5-10 seconds is typical), and return 200 as quickly as possible by offloading heavy processing to a background queue. Shopify considers any response taking longer than 5 seconds as a failed delivery and will retry it, potentially sending you duplicate events that your processing logic must be designed to handle idempotently.

Building Idempotent Webhook Handlers That Survive Retries

Idempotency means that processing the same webhook payload twice produces the same outcome as processing it once. Shopify will retry failed deliveries up to 19 times over 48 hours, so your handler will occasionally receive the same event multiple times — especially during deployments, network issues, or brief endpoint outages. If your handler isn't idempotent, retries can cause duplicate orders in your WMS, double loyalty point credits, or multiple confirmation emails sent to the same customer for the same order.

The standard solution is to log every processed webhook by its unique identifier before doing any work. Each Shopify webhook payload includes an id field (for orders, customers, and products) that is stable across retries. Before processing, check whether you've already seen that ID. If you have, return 200 immediately and skip processing. This check-and-skip pattern can be implemented with a simple database table or even a Redis set, and it takes roughly five lines of code to add to any existing handler.

Testing idempotency is as important as implementing it. Send the same webhook payload to your endpoint five times in quick succession and verify that only one downstream action occurred. Tools like SaltAI Agent for Shopify can help automate workflow testing and event handling across your Shopify integrations, reducing the manual effort of validating these edge cases at scale.

Monitoring, Debugging, and Maintaining Your Webhook Infrastructure

Shopify's Partner Dashboard provides a webhook delivery log for apps registered through the Partner program, showing recent delivery attempts, response codes, and response times. For custom apps, you'll need to build your own observability layer. At minimum, log the topic, the resource ID, the timestamp, and the HTTP response code for every webhook received. This log becomes invaluable when a merchant reports that an order "didn't sync" — you can immediately check whether the webhook was received, whether it was processed, and where in the pipeline it stopped.

Latency monitoring is equally important. If your average webhook processing time climbs above two seconds, you're at risk of Shopify treating deliveries as failures during any brief infrastructure slowdown. Set up alerts if your p95 processing time exceeds one second so you can investigate before it becomes a reliability issue. Free tools like Better Uptime or even a simple cron-based health check against your endpoint can provide early warning of problems before Shopify begins counting failed attempts.

Finally, plan for API version upgrades. Shopify updates its API quarterly and deprecates older versions on a rolling 24-month schedule. Webhook payloads change between API versions — fields are added, renamed, or removed. When you register a webhook via the API, it's tied to the API version you used for registration. Building a regular audit into your maintenance calendar — checking which API version each webhook subscription is pinned to — prevents the unpleasant surprise of a deprecated subscription stopping delivery with no immediate warning.

Conclusion

Shopify webhooks are the foundation of any real-time, reliable store integration. They eliminate polling overhead, reduce API consumption, and ensure your systems respond to store events within seconds rather than minutes. The key principles to carry forward are: register webhooks programmatically and verify they're active on startup, always validate HMAC signatures using the raw request body, handle retries with idempotent logic keyed on resource IDs, and build observability into your endpoint from day one. A webhook pipeline built on these principles will serve your store reliably whether you're processing 20 orders a day or 2,000.

Whether you're a founder running a single storefront or a developer managing integrations for a multi-channel operation, getting webhooks right is one of the highest-leverage technical investments you can make in your Shopify infrastructure.

Try SaltAI Agent for Shopify free at saltai.app — no credit card required.