Announcing Standard Webhooks
We're pleased to announce the launch of Standard Webhooks!
Kong has been part of the Technical Committee of this standard with other great companies like Svix (the initiator of the project), Ngrok, Zapier, Twillio, Lob, Mux, and Supabase. This was a year-long effort of gathering feedback, use cases, and debating about what and how to define what landed.
Standard Webhooks is one initiative to standardize the way producers and consumers can have a contract to communicate. This materializes by open-source repositories containing sets of guidelines and libraries to make those contracts secure and easy to integrate.
More details are available on the GitHub repository and the official website.
What are Webhooks?
Webhooks act as HTTP callbacks that enable services to notify one another about events. They function as a "reverse API," where instead of a client initiating requests to a service via an API call, the service proactively triggers a webhook to push updates to the client. For example, a service might trigger webhooks for events like "a user has paid" or "task is complete."
Webhooks facilitate server-to-server communication. The client/customer and the service providers involved typically operate their own HTTP servers — one server to receive API calls, and another to receive incoming webhooks. While webhooks often complement traditional APIs, this is not a requirement. Some services rely solely on webhooks for push notifications rather than offering APIs for clients to poll for updates.
Webhooks are becoming increasingly popular and are used by many of the world's top companies for sending events to users of their APIs. However, the ecosystem is fragmented, with each webhook provider using different implementations and varying quality. Even high-quality implementations vary, making them inherently incompatible.
For consumers, this means handling webhooks differently for every provider, relearning how to verify webhooks, and encountering gotchas with bespoke implementations. For providers, this means reinventing the wheel and redesigning for issues that have already been solved (security, forward compatibility, etc.). This fragmentation is a pain for the providers and consumers, stifling innovation.
The proposal is simple: standardize webhooks across the industry. We codified a set of strict webhook guidelines based on the existing best practices.
Another guiding principle was that it's better to have a widely adopted great spec than an unused perfect one. It's by this north star that the team is building a great developer experience toolset.
Why are we supporting this project?
If you're a Kong Konnect user, you might already be aware of the audit-logging feature which uses webhooks. This is Konnect's first webhook feature and engineering is working on more for 2024.
The lack of a standard in this ecosystem makes our implementations heterogeneous from the consumer point of view, as teams need to be in sync on how we expose X, Y, and Z. This leads to slower development and potential developer/consumer frictions.
From the engineering standpoint, Kong Konnect already consumes several vendor webhooks, and the “relearning how to verify webhooks, and encountering gotchas with bespoke implementations,” is definitely something we'd like to abstract from our developments.
Many other fields have been already solved, like authentication and authorization with OIDC, zero trust with mTLS, and API definitions with OpenAPI. Now it's the time for webhooks.
What's next?
As Kong is a core contributor to the project, we’ll strive to promote this standard via our products either in Kong Konnect, Kong Gateway, or Kuma.