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.
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.
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.
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.
Meet Emily. She’s an API product manager at ACME, Inc., an ecommerce company that runs on dozens of APIs. One morning, her team lead asks a simple question: “Who’s our top API consumer, and which of your APIs are causing the most issues right now?”
Ever feel like you're fighting an uphill battle with your API strategy? You're building APIs faster than ever, but somehow everything feels harder. Wasn’t API-first supposed to make all this easier? Well, you're not alone. And now industry analys
It’s been almost a year since we released our Konnect Terraform provider . In that time we’ve seen over 300,000 installs, have 1.7 times as many resources available, and have expanded the provider to include data sources to enable federated managem
In the last two parts of this series, we discussed How to Strengthen a ReAct AI Agent with Kong AI Gateway and How to Build a Single-LLM AI Agent with Kong AI Gateway and LangGraph . In this third and final part, we're going to evolve the AI Agen
In my previous post, we discussed how we can implement a basic AI Agent with Kong AI Gateway. In part two of this series, we're going to review LangGraph fundamentals, rewrite the AI Agent and explore how Kong AI Gateway can be used to protect an LLM
This is part one of a series exploring how Kong AI Gateway can be used in an AI Agent development with LangGraph. The series comprises three parts: Basic ReAct AI Agent with Kong AI Gateway Single LLM ReAct AI Agent with Kong AI Gateway and LangGr
What Is RAG, and Why Should You Use It? RAG (Retrieval-Augmented Generation) is not a new concept in AI, and unsurprisingly, when talking to companies, everyone seems to have their own interpretation of how to implement it. So, let’s start with a r