Webhooks

A pattern where a provider POSTs events to your HTTP endpoint as things happen, instead of you polling their API.

A webhook is a callback you register with another service: when something happens on their side, a payment succeeds, a repo gets pushed, an email bounces, they send an HTTP POST describing the event to a URL you control. It inverts polling: instead of asking every minute, you get told the second something changes.

Why it matters to an indie builder: Stripe, GitHub, Shopify, Postmark and effectively every SaaS you will integrate with speak webhooks. They are how your app reacts in real time to money and delivery events without rate-limited polling loops burning your API quota. The catch: the responsibility flips. Polling is trivial to write and forget; a webhook endpoint is a public HTTP service that must be fast, verified and idempotent.

A concrete example: subscription cancellations. Polling the billing API hourly costs 720 calls a day and learns about churn up to an hour late. With a webhook, the provider POSTs the cancellation event the moment it happens, your handler downgrades the account and sends a save email. Detection latency drops from an hour to seconds and the cost is effectively zero.

Common mistakes, each one a real production incident: doing slow work inside the handler (return 2xx immediately, process from a queue, or retries will pile up), skipping idempotency (providers retry on timeout, so the same event arrives three times; dedupe on the event id), not verifying the signature (anyone who finds your URL can POST a fake payment succeeded; check the HMAC header against the shared secret), and never looking at delivery failure logs, which is how silently broken webhooks leak revenue for months. The billing and email-delivery blocks on IndieBoot all ship webhooks; treat their docs' security sections as required reading.