Webhook: an inverted API where the provider sends an HTTP POST to your registered URL on an event. This avoids the latency and waste of polling, delivering near-real-time updates.
2 / 5
Why should webhook consumers verify a signature (e.g., HMAC) on incoming payloads?
Signature verification: the provider signs the payload with a shared secret (HMAC). The consumer recomputes the signature to authenticate the sender and ensure integrity, preventing spoofed webhook calls.
3 / 5
Why must webhook handlers be idempotent?
Idempotency: at-least-once delivery means duplicates happen, especially after retries. Handlers should use an event ID to deduplicate so processing the same event twice does not double-charge or double-create.
4 / 5
Why is it best practice to return 200 quickly and process work asynchronously?
Fast ack: acknowledge receipt immediately, then enqueue the payload for background processing. Doing heavy work synchronously risks exceeding the provider's timeout, triggering duplicate deliveries.
5 / 5
What is a robust strategy for handling repeated webhook delivery failures?
Retry with backoff: providers (and good consumers) retry failures with increasing delays. After exhausting retries, the event should land in a dead-letter queue or log for manual inspection rather than being lost.