Cybersecurity glossary
What is a Webhook?
Learn what a webhook is, how providers push event HTTP callbacks to your endpoints, how to verify signatures, and how to handle retries and idempotency safely.
Definition
A webhook is an HTTP callback mechanism where a provider sends an event notification—usually a POST with a JSON payload—to a URL you register, so your system can react to changes without continuously polling the provider’s API.
Why webhooks matter
Polling partner APIs every few seconds wastes quota and still leaves you late to the party. When a payment clears or a scan finishes, you want to know immediately.
A webhook flips the relationship: the provider pushes an event to your HTTPS endpoint. Integrations become faster and lighter—if you verify authenticity and tolerate duplicates.
How a webhook delivery works
You register a callback URL
Usually an HTTPS endpoint in the provider’s dashboard or API, sometimes with a secret.
An event occurs upstream
Payment captured, issue opened, domain verified—whatever the product emits.
Provider POSTs a payload
JSON body plus signature headers and an event ID are common.
Your endpoint verifies and acknowledges
Validate signature/time, then return 2xx quickly if accepted.
Work is processed (often async)
Enqueue durable work so slow jobs do not cause provider timeouts.
Retries happen on failure
Timeouts and 5xx responses typically trigger redelivery with the same event ID.
Webhooks vs polling vs websockets
| Model | Who initiates | Best for |
|---|---|---|
| Webhook | Provider → your server | Server-side integration events |
| Polling API | Your server → provider | Simple setups; weaker real-time needs |
| WebSocket/SSE to browsers | Your server → clients | Pushing updates to user interfaces |
Security controls that matter
Verify signatures
HMAC or asymmetric signatures prove the provider sent the body you received.
Reject replays
Check timestamps and remember processed event IDs within a retention window.
Use HTTPS only
Secrets and PII in webhook payloads must not travel in cleartext.
Authenticate the destination
Hard-to-guess URLs alone are not enough; rotate shared secrets.
Least privilege processing
Webhook workers should not have broader credentials than the events require.
Rate-limit and size-cap
Defend against floods and oversized JSON bombs on public endpoints.
Reliability patterns
Idempotent handlers
Process each event ID once even when the provider delivers three times.
Fast ACK, async work
Return 2xx after durable enqueue; do heavy side effects in workers.
Poison message handling
Bad payloads should not block the queue forever—quarantine and alert.
Outbound egress control
If you also send webhooks, prevent SSRF-like callbacks to internal IPs.
Practical checklist
- Require signature verification before any business side effect.
- Store and dedupe provider event IDs with a documented retention period.
- Acknowledge quickly; move slow work to an idempotent queue consumer.
- Rotate webhook secrets and support dual-secret windows during rotation.
- Log event type, ID, verification result, and processing outcome.
- Alert on sudden spikes in failures, signature mismatches, or latency.
- If you send webhooks, validate target URLs against private IP ranges.
- Document retry schedules so on-call knows why duplicate events appear.
The practical takeaway
A webhook is an event-driven HTTP callback from a provider to your system. It reduces polling and improves timeliness—while introducing forgery, replay, and duplicate-delivery risks.
Verify every delivery, acknowledge fast, process idempotently, and treat webhook endpoints as public attack surface with the same rigor as login APIs.
Related security terms
Idempotency
Essential because webhook deliveries are typically at-least-once.
Idempotency Key
Related dedupe patterns; webhooks often use provider event IDs instead.
Server-Sent Events (SSE)
A different push model where your server streams to clients.
API Abuse
Unauthenticated webhook endpoints are easy abuse targets.
Rate Limiting
Protects receivers from flood bursts and retry storms.
Frequently asked questions
What is a webhook in simple terms?
It is a phone call from another system to yours: when something happens (payment succeeded, repo pushed), they POST the details to a URL you gave them.
How is a webhook different from an API?
You call APIs to pull data. Webhooks call you to push events. Many integrations use both.
Why do webhooks retry?
Providers usually guarantee at-least-once delivery. If your endpoint times out or returns 5xx, they try again later.
How do I know a webhook is authentic?
Verify signatures or HMAC headers with a shared secret, check timestamps to limit replay, and optionally pin source IPs if the provider publishes them.
Should webhook handlers be fast?
Yes. Acknowledge quickly (2xx) and process asynchronously when work is heavy, or providers will retry and pile up duplicates.
What happens if I expose a webhook without auth?
Attackers can forge events—fake payments, trigger provisioning, or flood your workers.
Are webhooks always HTTPS?
They should be. Cleartext webhook URLs expose secrets and payloads on the network.
References
Explore authoritative guidance and frameworks related to webhook.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.