What Are They
Webhooks, like APIs, are a way for two applications to talk to each other. The main difference between an API and a webhook is what you use them for.
Use Case
APIs are structured around a request and a response. To follow the simple example from our API explanation, you might make a request to your rating engine with the details of a risk you're quoting, and the rater will respond with the premiums. APIs are inherently a two-way affair.
Webhooks instead are for events. Say you've used a no-code platform to build out an online quote and purchase flow, for example. And every time a customer purchases a policy through that platform, you need to know about it. It wouldn't really do to keep sending API requests every few seconds: “Has there been a purchase now? How about now?” Instead, the platform uses a webhook to simply tell you when it's happened.
Who Writes the Specs
Now, you could turn that scenario on its head. Couldn't you have an API for “registering that a policy's been sold,” and ask the no-code vendor to call it?
And the answer is, you could. In fact you very well may have such an API. But using webhooks is a much more scalable and clean-cut solution:
- Your no-code vendor writes the specs for exactly what to expect in its webhooks.
- Whoever created your system of record writes the specs for exactly what it needs in an API call.
- What's left is to write an orchestration layer to coordinate the two, and translate from one set of specs to the other.
“Reverse APIs”
For reasons we hope should be intuitive by now, webhooks are sometimes referred to as “reverse APIs.”
- Instead of your application reaching out to the no-code platform for information, you're asking the platform to reach out to you when there's been a purchase.
- Instead of the side receiving the call writing the specs, it's the sending side that call the shots.
If this term helps you remember what they are, we encourage you to use it!