HookRescue vs building it yourself
The DIY version is a known, finite engineering project — a few weeks of work for an experienced Rails or Node team. Worth doing if webhook reliability is core to your product. Worth buying if it isn't. Here's the realistic scope.
Last reviewed · Pricing captured 2026-05-11 · Sources cited inline.
What "build it yourself" actually means
The full DIY stack for Shopify webhook reliability has six moving parts. Each is non-trivial. None is so hard that a working engineer can't get there. The cost is mostly time + tail-risk of operational issues you don't anticipate.
1. HMAC verification middleware
Trivial to get wrong. The bug surface is that frameworks parse the body before you see it, which breaks HMAC. In Rails you read request.raw_post from middleware before any controller runs. In Express you use express.raw({type: '*/*'}) only for the webhook routes. In Next.js App Router you call request.text() instead of request.json(). Constant-time comparison is mandatory. Reasonable scope: 2–4 hours including tests.
2. Inbound queue + immediate ack
Webhook handler returns 200 in under 5 seconds or Shopify retries. Synchronous processing is what kills most reliability stories. The standard pattern: receive, persist to a durable queue, ack 200, process async. Sidekiq + Redis or BullMQ + Redis or SQS — whatever fits your stack. Reasonable scope: 4–8 hours.
3. Dedup table
Unique index on (topic, X-Shopify-Event-Id). Reject duplicates at the index level, not in application code (race conditions). TTL or cleanup job to keep the table bounded. Reasonable scope: 1–2 hours.
4. Retry curve
Shopify gives up after 4 hours. Your queue should keep retrying past that for transient outages. Sidekiq's default exponential backoff goes 25 retries over ~21 days — too aggressive. A 7-day curve with sane backoff is more typical. Reasonable scope: 2–4 hours to configure and test.
5. Subscription health monitoring + auto re-registration
The one that bites teams that didn't budget for it. You need a cron that:
- Queries
webhookSubscriptionsvia the Admin GraphQL API on a schedule. - Compares the returned topics to your expected list.
- Calls
webhookSubscriptionCreatefor anything missing. - Alerts you when a re-registration happens, so you can investigate root cause.
Add per-merchant scope if you're a Shopify app with multiple installed stores. Reasonable scope: 1–2 days, including the alerting plumbing.
6. Admin API reconciliation
The post-incident recovery layer. When the retry curve fully closes and events are permanently gone from Shopify's queue, the Admin API is your remaining source of truth. The flow:
- For each high-stakes topic (orders/create, fulfillments, etc.), query the Admin API for records created or updated in a recent window.
- Diff against your local store.
- Synthesize webhook-shaped payloads for the gaps, re-sign with your client secret, replay through your handler.
- Track which events were synthesized vs original (for audit).
The bulk-operations API is the right tool for the diff query — async, no rate-limit pressure, JSONL output. Plumbing it into a sensible cron, deduplicating against already-received events, and re-signing payloads correctly is a real project. Reasonable scope: 3–5 days for one topic; another 2–3 days per additional topic.
Total cost ballpark
| Component | Time | Notes |
|---|---|---|
| HMAC + inbound queue + dedup | ~1.5 days | Well-known patterns, mostly |
| Retry curve config + tuning | ~0.5 days | Sidekiq / BullMQ tune |
| Subscription health monitoring | ~1–2 days | Cron + diff + alerts |
| Admin API reconciliation (orders) | ~3–5 days | Most of the work lives here |
| Dashboard + audit log + replay UI | ~3–5 days | Optional; you can defer until needed |
| Total realistic build | ~2 weeks | Mid-level engineer, one topic |
That's the build cost. The ongoing operational cost — incident response, retry tuning, dealing with subscription removal at 3am, audit trail compliance — is the part that's hard to estimate up front because most of it shows up as a stream of "small" tickets.
When you should build it yourself
- Webhook reliability is part of your product's value proposition — your customers depend on it, you charge for it, your engineering team should own it end-to-end.
- You have specific reliability requirements (regional compliance, on-prem retention, custom transformations) that off-the-shelf relays can't satisfy.
- You're already running similar infrastructure for other event streams and adding Shopify to it is incremental work, not greenfield.
- Your event volume is genuinely massive (millions per day) and even a flat-rate relay would cost more than the engineering time amortized.
When you should buy
- Shopify webhooks are infrastructure your product depends on but isn't the product. You'd rather your team ship the actual product.
- You've already lost data once and don't have the operational maturity to make sure it doesn't happen again.
- You need an audit trail for compliance and don't want to build dashboards.
- You're a Shopify app developer and the compliance webhook handling (the three mandatory GDPR topics, the 30-day deadline) is on your plate before App Store review.
The hybrid path
Most teams end up in the middle. They build HMAC + inbound queue + retry curve themselves — that's well-understood infrastructure and they want to own it. They buy or skip the parts that require Shopify-specific knowledge: Admin API reconciliation, subscription auto-recovery, compliance webhook handling.
If you're considering this, our position is straightforward: use whatever queue and HMAC verification you already have. Point your Shopify webhook subscriptions at our ingest URL instead of yours; we forward to your existing handler. You keep ownership of your code. We handle the Shopify-specific parts that aren't worth re-implementing from scratch.
Sources
- shopify.dev — subscribe via HTTPS (retry policy)
- shopify.dev — ignore duplicates (X-Shopify-Event-Id semantics)
- shopify.dev — bulkOperationRunQuery (reconciliation tool)