Production notes on delivery, retries, signature verification, debugging, and replay, from the team building AnyHook.
All posts
GitHub does not retry failed webhook deliveries. Not once. The delivery record survives for three days and then it is gone too, which makes this the only major provider where a bad deploy costs you events permanently.
HubSpot does not guarantee ordering, batches notifications into arrays, and documents its eventId as not guaranteed to be unique. Every instinct you built on Stripe's event.id fails here. What to dedupe on instead.
Identity webhooks fail asymmetrically. Miss access.granted and a user files a ticket. Miss access.revoked and nobody files anything, because from the outside everything still works. Your webhook receiver's uptime is an access control.
Merchant of record billing has a much tighter response budget and a far denser retry curve than Stripe. What changes when you move an indie SaaS from Stripe to Paddle or Lemon Squeezy, and why a slow handler hurts more here.
Slack's Events API wants a 2xx within three seconds, retries three times, and disables your subscriptions if you fail 95% of deliveries in an hour. It is the only webhook failure your users watch happen in real time.
Twilio is the only major sender that lets you configure the connect timeout, the read timeout, the total time, the retry count, and which failures are worth retrying. Five parameters, all with defaults nobody revisits.
No Node crypto, no request-scoped filesystem, a CPU budget measured in milliseconds, and waitUntil that is not durable. What actually changes when the webhook receiver is a Worker, taken from AnyHook's own ingress.
WooCommerce queues deliveries through Action Scheduler, which runs on WP-Cron, which runs when somebody visits your site. On a quiet store that is minutes of delay. After five consecutive failures the webhook is disabled outright.
Every major webhook provider delivers at-least-once, which means duplicates are guaranteed, not exceptional. Here is why the alternative is worse, and four idempotency patterns ranked by how much they actually protect you.
Nine times out of ten it's the test URL, and the test URL only listens while you're watching. The rest of the time it's response mode, a consumed raw body, or the fact that a failed n8n execution loses the event permanently.
Shopify gives your endpoint five seconds to respond, retries eight times over four hours, then removes the subscription entirely if failures continue. Nothing throws. Orders just stop arriving. Here is how to survive the 5-second budget.
Stripe emailed you that your webhook endpoint is disabled. You have a 30-day window to recover the events you missed, and it is smaller than it sounds. Here is the exact sequence: re-enable, backfill from the Events API, and make it not happen again.
Signature checks that fail for no reason, waitUntil work that vanishes, and cold starts that eat a provider's timeout budget. The five things that actually bite when a webhook handler runs on serverless, and what to do about each.
Polling wastes requests but degrades gracefully. Webhooks are efficient but fail silently. The honest comparison, including the hybrid almost every serious integration ends up building, and why.
Agents can send HTTP anywhere, but half the internet still answers by email: verification codes, receipts, notifications. One keyless call gives an agent a real inbox whose mail becomes webhook events it can read back over the same API.
A catch-all address, a Worker email handler, and about sixty lines: every email to your domain becomes a JSON POST to your existing HTTP pipeline. The design decisions that matter: address parsing, SMTP-time rejection, and not building a second pipeline.
A webhook log in a mutable database is a claim, not evidence, because whoever holds the database can rewrite it. How we made AnyHook's event log verifiable by anyone: per-app hash chains, daily seals, and anchors published to a repository we hold no credentials for.
If your test builds the signature with the same formula your verifier checks, both can be wrong together and stay green. How to cross-check webhook verification against the provider's own SDK, and the real bypass we found the same day we started.
AI agents can call APIs, but receiving events is the missing half. What breaks when an agent tries to get a webhook endpoint, and what an agent-operable webhook service actually looks like.
Stripe 大概給你 20 秒，OpenAI tool call 跑 45 秒。Webhook 同步處理 AI 推論的時間錯位，是 2026 年最常見的雙重扣款來源。這篇講為什麼會壞，以及正確的 edge ack + async deliver 做法。
A practical framework for debugging webhook delivery issues: what to look for in headers, status codes, timing, and payloads when your integration stops working.
Why naive exponential backoff causes thundering herds, how jitter fixes it, and what production-grade retry schedules actually look like.
Your server went down for an hour. Stripe, GitHub, and Shopify kept sending webhooks. Here is how to replay the events you missed, with and without a webhook relay.
ngrok is great for local dev. It's not a production strategy. Here is what you need past the tunnel, for staging, production, and the gray area in between.
Stripe retries failed webhooks for up to 3 days. Here is how the schedule works, what breaks when your endpoint is down, and how to design for it.
A practical guide to verifying webhook signatures across providers: what can go wrong, how timestamp tolerance works, and why retries break naive implementations.
Change one URL, get automatic retries, full event log, and one-click replay. Free plan, no credit card.