4 questions developers actually get asked about webhooks — with clear, practical answers you can use to prepare.
A webhook is an HTTP POST that one service sends to a URL you own, automatically, the moment a specific event happens. A regular API call is the opposite direction: your code calls the service and asks for data. Webhooks push; APIs pull. Webhooks are right when you want real-time notifications without having to poll.
Your webhook URL is public, so anyone on the internet can send a POST to it. Without verification, an attacker could fake a "payment.succeeded" event and trick your app into delivering a product or upgrading a subscription for free. Signature verification uses a shared secret (provided in the sender's dashboard) to prove the request actually came from the real service, and the payload was not tampered with.
Webhook senders retry if they do not get a 2xx response in time, which means the same event can arrive two or more times. The fix is idempotency: store each event ID when you process it, and on every new webhook check if you have already handled that ID. If yes, return 200 immediately and do nothing else. This guarantees that processing the same event N times has the same effect as processing it once.
Most providers (Stripe, GitHub, Shopify) expect a response within 5 to 30 seconds. If you do heavy work, like sending emails or writing to a slow database, before you respond, the provider assumes your endpoint failed and retries. That causes duplicate events and alerting noise. The standard pattern is to validate the signature, acknowledge with 200 OK, and do the actual work asynchronously (background job, queue, or worker).
Want the full concept, analogies, and AI prompts for webhooks?
Read the full Webhooks block →