Webhooks are a way to communicate between applications by sending data to another application when an event occurs. Webhooks are HTTP-based callback functions that are automated and triggered by an event in a source system, then sent to a destination system, providing event-driven capabilities utilizing simple HTTP "reverse APIs".

Also known as: HTTP callbacks, Reverse APIs, Event notifications

Standards

• Community / Industry consortium Standard Webhooks
• OpenAPI Initiative OpenAPI 3.1 — webhooks (top-level)
• AsyncAPI Initiative AsyncAPI 3.0 (suitable for describing webhook channels)
• W3C WebSub
• CNCF CloudEvents 1.0.2
• IETF HTTP Signatures (RFC 9421)
• IETF RFC 9110 — HTTP Semantics

HTTP Headers

Status Codes

• 200 OK — Convention — Most senders treat any 2xx as successful delivery.
• 410 Gone — RFC 9110 §15.5.11 — Conventional signal to the sender that the endpoint is permanently disabled.
• 429 Too Many Requests — RFC 6585 — Backpressure signal; senders should honor Retry-After.

Media Types

• application/json — Default payload format for most webhook providers.
• application/cloudevents+json — CloudEvents — Standardized event envelope.

OpenAPI Expression

• webhooks (OpenAPI 3.1) — Top-level map describing incoming webhook operations the API may send to subscribers.
• components.callbacks (OpenAPI 3.x) — Callback objects describing out-of-band requests triggered by an operation.

Governance Rules

• webhook-signed (Convention / Standard Webhooks) — Every webhook delivery must carry a verifiable signature.
• webhook-timestamp-verified (Convention / Standard Webhooks) — Receivers must reject deliveries older than a tolerance window (e.g. 5 minutes) to prevent replay.
• webhook-idempotent-id (Convention) — A stable delivery id must be present so receivers can dedupe retries.
• webhook-retry-policy-documented (Convention) — Senders should document retry schedule, max attempts, and dead-lettering.

Risk & Compliance

OWASP:

• OWASP API Security Top 10: API7:2023 Server Side Request Forgery — outbound webhook URLs can target internal hosts
• OWASP API Security Top 10: API2:2023 Broken Authentication — unsigned or weakly-signed deliveries are spoofable
• OWASP API Security Top 10: API8:2023 Security Misconfiguration — receivers often skip TLS verification or signature checks

Compliance:

• PCI DSS v4 Req. 4 — encrypt deliveries in transit
• GDPR Art. 32 — integrity controls on event payloads carrying personal data
• SOC 2 CC6.7 — protections on data in transmission

Security: Webhooks are an outbound and inbound attack surface. On the sender side, validate destination URLs (block private ranges, enforce TLS, allow only http/https), sign every payload, and rotate signing secrets. On the receiver side, verify signatures and timestamps before doing any work, dedupe on the delivery id, return 2xx fast and process asynchronously, and treat the payload as untrusted input.

Tools

• Svix — Webhook delivery platform
• Hookdeck — Webhook gateway
• ngrok — Local tunnel for development
• webhook.site — Inspection / debug
• smee.io — Webhook proxy
• Standard Webhooks libraries — Signing / verification libraries (MIT)

Suggested Metrics

• webhook_delivery_success_rate — Share of deliveries acknowledged with a 2xx on first attempt.
• webhook_delivery_latency_p95 — 95th-percentile time from event to acknowledged delivery.
• webhook_retry_rate — Share of deliveries requiring at least one retry.
• webhook_dlq_depth — Number of deliveries currently in the dead-letter queue.
• webhook_signature_failure_rate — Share of inbound deliveries rejected for signature or timestamp failure.

Example Implementations

• Stripe — Signed webhooks with Stripe-Signature header and replay-protection timestamp.
• GitHub — HMAC-SHA256 signatures via X-Hub-Signature-256.
• Slack — Events API with signed payloads and URL verification challenge.
• Shopify — HMAC-SHA256 signatures via X-Shopify-Hmac-Sha256.

Related Properties

• Asyncapi
• Openapi
• Json schema

Tags

• Webhooks
• Event-Driven

All Community Properties