Comparing the most popular webhook providers

We’ve published a series of articles reviewing various webhook providers and have noticed some interesting commonalities and differences between them. In each of the articles, we take a look through the webhook provider’s documentation to see if and how they implement 7 key features we believe help make a great webhook experience: automatic retries, exponential backoff, signature verification, manual retries, event types, multiple endpoint support, and log visibility. We tried to select the most popular webhooks by looking at google search volumes. Here is the summary table of our reviews:

Only Stripe, GitLab, and Svix check all 7 boxes (since Svix is a webhook service, all Svix customers check all the boxes as well 😉). Shopify came close with 6 boxes but the rest have at best 3. A round of applause for Stripe, GitLab, and Shopify please!

All 7 offer multiple endpoint support so it seems we’re past the days of having to receive all your webhooks on one endpoint. Event Types were offered by 6 of the companies and DataDog had a unique design for filtering which events you receive via custom variables. This combination of features can make webhook consumers’ lives much easier by allowing them to have separate endpoints for each Event Type. It makes debugging failing endpoints much easier and adds resilience to their system so one failing endpoint doesn’t block all webhook messages from being received.

Signature verification was offered by most companies which was a relief as its a critical component to offering a secure webhook service. We suspect this will become table stakes for any webhook provider very soon.

Manual retries were only offered by Stripe and GitLab and was the only feature not offered by Shopify. This suggests it's the most “nice to have” feature on our list. It does make developers’ lives a lot easier when they’re debugging a failing endpoint and can trigger a retry manually instead of having to wait for the retry schedule.

We were most surprised by the retry policies (a combination of having automatic retries sent with an exponential backoff schedule). For a few of the companies that we didn’t give checkmarks to offer retries but the number of retries are very low. It felt like they were just trying to check a box instead of focusing on how a retry policy can improve the developer experience. We believe having a retry policy that sends retries over at least a 24h span is necessary to give developers time to fix their failing endpoints before they get disabled.

Overall, we were very impressed with some webhook services and a bit disappointed by others. This just goes to show how difficult webhooks can be to implement at the scale some of these products have achieved.