Standard Webhooks is a set of open source tools and guidelines to send webhooks easily, securely and reliably. Webhooks are becoming increasingly popular, though every webhooks provider implements them differently and with varying quality. This makes it hard for providers who need to reinvent the wheel every time and repeat the same costly mistakes, and annoying for consumers who need to have a different implementation for each provider. It's also holding back the ecosystem as a whole, as these incompatibilities mean that no tools are being built to help senders send, consumers consume, and for everyone to innovate on top, unless we invest in the following areas. * **Security** - Every webhook implementation needs to protect themselves and their users from SSRF, spoofing, and replay attacks. * **Interoperability** - Make it easier for your users to consume your webhooks by making them Standard Webhooks compliant. * **Reliability** - Standard webhooks is designed by experts with extensive experience building reliable and scalable webhook services. Webhooks are a common name for HTTP callbacks, and are how services notify each other of events. Webhooks are part of a service's API, though you can think of them as a sort of a reverse API. When a client wants to make a request to a service they make an API call, and when the service wants to notify the client of an event the service triggers a webhook (“a user has paid”, “task has finished”, etc.). Webhooks are server-to-server, in the sense that both the customer and the service in the above description, should be operating HTTP servers, one to receive the API calls and one to receive the webhooks.It's important to note that while webhooks usually co-exist with a traditional API, this is not a requirement, and some services send webhooks without offering a traditional API.
Standard Webhooks
Standard Webhooks is an open specification and set of tools for sending webhooks in a consistent, secure, and reliable way. It exists because every provider has historically implemented webhooks differently — different signing schemes, payload shapes, and retry behavior — forcing senders to reinvent the wheel and consumers to write bespoke integration code for each provider. By defining one common approach, it aims to do for event callbacks what OpenAPI did for request/response APIs.
- Signature verification - A standardized HMAC signing scheme lets consumers confirm a payload genuinely came from the sender and was not tampered with.
- Replay protection - Timestamped signatures and message IDs defend against replay attacks and let receivers deduplicate events.
- Consistent payload structure - A predictable envelope for event type, ID, and data makes handlers portable across providers.
- Reference libraries - Open source SDKs in many languages implement the spec so teams verify and consume webhooks correctly instead of rolling their own.
In real API operations, Standard Webhooks gives the event-driven half of an API the same governability the synchronous half already gets from OpenAPI and AsyncAPI. Adopting it means a provider’s callbacks can be validated, mocked, and consumed with shared tooling rather than provider-specific glue — and as agents increasingly react to events rather than poll for them, a signed, standardized webhook becomes a trust signal that the notification is authentic and safe to act on.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
Adyen Makes Good Use of OpenAPI Webhooks
2025-01-24
Making An Account Activity API The Default
2017-06-29
