Webhooks are how servers notify each other of events, so they are a key component of many APIs such as Stripe, Shopify, Slack, Dropbox and Github. They look easy to implement (just a POST request), but they come with a variety of challenges. For example, customer endpoints fail or hang much more often than you would think, so you would need to implement retries. You need to make sure such failures don't clog your send queue or the rest of your system. The webhook system is an additional system separate from your normal web server that needs to be scaled and monitored separately. There are also a variety of security implications such as SSRF, replay attacks, and attackers sending fake webhooks to your customers (so make sure to sign the payload and make it easy to verify!). You also want to avoid overloading your users' endpoints, so you want to automatically rate-limit webhook sending, as well as disabling failing ones, and notifying your users when you do.
I encountered these challenges at my previous company. Our users were constantly asking us for webhooks, but we kept deferring building them because we weren't willing to commit the engineering time, resources, and ongoing maintenance required of a webhook delivery system. This was the seed for Svix, but it's only after a friend of mine asked about adding webhooks to her own product that I realized "Oh, there's maybe a business here".
The idea behind Svix is to make it very easy for everyone to send webhooks. Developers make one API call and we take care of deliverability, monitoring, and retries. We also have a pre-built management UI that our customers can offer their users to manage their webhook endpoints, as well as inspect, debug, and replay failures. This is in addition to a variety of tools, libraries, and tutorials to make both sending and consuming webhooks easy.
We have previously done a Show HN (https://news.ycombinator.com/item?id=26399672) and got a lot of great feedback from the community. A lot has changed since then, for example, we now have libraries for Python, JavaScript (TypeScript), Java and Go; a first version of the Ruby and PHP libraries, and a CLI for interacting with the service. We have improved the management UI, made it easy to embed it in an iframe, and improved the onboarding and documentation to make it even easier to get started. And finally, we have scaled the backend to keep up with the growing needs of our customers. We have a lot more planned for the coming months, and we've grown the team so improvements are going to come at an even higher pace.
One of the common questions from our Show HN was: "Don't developers need to handle deliverability and retries to Svix?" Deliverability to user endpoints (servers) is very different to deliverability to Svix. User endpoints fail all the time and for various reasons, and each of them can fail independently. This means developers need a robust and scalable delivery system that can deal with failures on an ongoing basis. With Svix, outages are rare, and are dealt with as incidents, the same way you would with SendGrid, Twilio and other API providers.
Our goal with Svix is to make it easier for developers to add webhooks to their service. Webhooks make APIs that much more useful and enable a lot of automations and integrations which benefit both the products offering them, and the communities around them. Just think of all the cool Slack bots made possible thanks to webhooks. I'd really love to see every service out there offering a great API!
I'd love to hear about your experience building (or using) webhooks systems. What's a must have? Any war stories to share? Got any questions? Suggestions? Please let me know!
Docs: https://docs.svix.com/
Docs for consuming webhooks: https://docs.svix.com/receiving/introduction
API viewer (and OpenAPI specs): https://api.svix.com/docs/
by Andrey
Azimov