In 2023, we looked at the top 100 API companies along with internal Svix data to examine how often webhook best practices are implemented across the industry and what type of impact these practices have on the reliability and scalability of webhook systems.
This year we looked at the same 100 companies to see if and how much adoption of webhooks and implementation best practices has increased. We also looked at over 100 new companies classified as startups by Forbes in 3 different industries: Fintech, Developer Tools, and AI to compare webhook adoption rates across industries as well as by the stage of the company.
We’re very pleased to report an increase across the board in webhook adoption and implementation of best practices. We’d like to think one of the major contributing factors to the trend is the release of the Standard Webook specification which outlines best practices for an outbound webhook service and continuing demand from webhook consumers for more reliable and secure webhooks.
Last year, 83 of the top 100 APIs we analyzed offered webhooks. When we looked at the same 100 APIs this year, there was a small increase to 85% webhook adoption.
One question we wanted to answer in this edition of the State of Webhooks, was whether startups are more or less likely to offer a webhook service than established API providers. On one hand, startups tend to adopt new technologies faster but webhooks tend to be a feature that get added post launch of an API.
We took the startups from the Forbes Fintech 50 and AI 50 lists as well as Failory’s top 59 DevTool startup lists and analyzed them the same way we did the API top 100. Clearly, startups are lagging a bit on webhook adoption, especially in AI which tends to be more consumer focused businesses.
Retries (re-sending a webhook if an attempt fails) are one of the foundational components of a reliable webhook system so we’re thrilled to see an increase in adoptionfrom 67% to 73%.
We also saw increases in the number of retries offered with a decrease in the number of services offering only 1 retry and increases in the number of services offering 5+ retries.
Similar to how startups were lagging in overall webhook adoption, they also lag in adopting retries. There is a significantly lower adoption rate specifically for Devtool startups which was unexpected.
Fintech represents the highest adoption rate of retries which makes sense given how critical it is to respond to financial events in real time and to not miss/lose any transaction data.
Progressively increasing the wait time between retries reduces the risk of making any server issues worse, deals with transient issues by sending the first few retries quickly, and gives users plenty of time to fix failing endpoints.
Adoption of an exponential backoff schedule for retries also increased from 25/83 (30%) to 31/83 (37%).
The narrative around exponential backoff adoption for startups is very similar to the adoption of retries overall. Fintech startups lead the way with Devtool startups lagging significantly.
On a % basis, the largest increase in adoption among all the best practices we analyzed was the implementation of manual retries (+71%). Of course it was the lowest adopted best practice in the 2023 report and had the most room for improvement.
Being able to retry messages manually speeds up troubleshooting. It is faster to trigger a retry immediately instead of waiting for the next automatic retry.
It’s a nice trend to see and should make webhook consumers’ lives much easier when troubleshooting failing endpoints or simply needing to send test events during initial setup and testing.
One of the most surprising results was the rate at which AI startups adopt manual retries. Our best guess as to why the adoption rate among Fintech startups is so low here compared to the other best practices is that there is usually a large volume of messages in financial systems so the ability to retry a single transaction is rarely necessary.
When you have a high volume of messages you’ll usually want to retry all failed messages in bulk or in batches. AI products tend to have lower message volume.
Another large percentage increase was in the number of services offering message history logs. This is a great feature that lets users self-service the troubleshooting of failing endpoints.
Not only does this benefit the consumer who doesn’t have to wait on a response from support to get answers on why they aren’t receiving their expected events, but its also beneficial for the webhook provider as they receive significantly less support requests around webhook failures.
Issues also get resolved faster when developers can self diagnose their issues so this feature is a win-win for everyone.
Another curious result is that the adoption of logging and monitoring of messages is fairly even across the board between the top 100 API providers vs startups, and across industries.
This suggests that the ability to self diagnose and troubleshoot failures is not unique to any particular field or stage of company and is just something all webhook consumers want and benefit from greatly.
Event type adoption was essentially the same (93% vs 94%) as the adoption rate was so high to begin with. This is simply because event types are a core feature of any webhook implementation as you need to let users know what event they are receiving.
Curiously, event type adoption was very low for AI startups. In the API 100, the only implementations without webhooks were those with only one event so perhaps AI companies only have one event to offer.
Again, we see an uptick in the adoption of message authentication best practices (HMACSHA256). We see this increase coming relatively evenly from a decrease across all alternative authentication methods, but particularly from implementations that were simply passing a Bearer token.
Adoption of HMACSHA256 is similar across the board. The outlier results come from the AI 50 where passing a secret directly in the header is very popular. Interestingly, this accounts for how few of the AI 50 offer no webhook authentication at all.
Including the timestamp as part of the hashed content when generating HMAC signatures helps prevent replay attacks. Without the timestamp as part of the signature, old messages can be duplicated and sent again which can be a major issue if a financial institution processes the same transaction twice.
More of the same with timestamps in the signature. Established API providers outperform startups when it comes to implementing best practices.
Good documentation is critical to providing an excellent developer experience. This is especially true for webhooks which have several “traps” that developers can fall into when trying to implement their endpoints. Having extensive documentation can help users avoid these pitfalls and save a lot of time and frustration.
One thing we see from the best webhook services is instructions on testing. This also includes troubleshooting tips for common issues like failing signature verification.
When it comes to documentation, startups are on par with more established webhook providers. This is also logical as documentation is fundamental to all products.
A key element we see as an indicator of good webhook documentation is code samples. This applies to most API documentation but particularly for webhooks. It’s extremely useful to have examples of working webhook endpoints for users to understand exactly what their endpoints need to do and how to do it.
Along with everything else we’ve seen in the report so far, we also saw more code samples. This is a direct reflection of the increase in the number of providers offering HMAC signature authentication. If providers do not offer authentication at all or are offering simpler methods like basic auth or a simple secret header, there is less need for a code sample as the implementation is much simpler.
Here most webhook providers whether established or startup are offering code samples to their users. The exception is with AI companies who tend to not offer HMAC signatures and lean towards secret headers for authentication.
Perhaps AI users are not as technical or security conscious as Fintech and Devtool consumers and a simpler authentication method is best for their use case. It also seems likely that AI products have a core user base of consumers and their APIs and webhooks are a secondary offering for a small % of their users and so less effort has been invested in making their webhook services more secure/robust.
We’re happy to report that after updating our research, we saw an increase across the board for general adoption as well as implementation of best practices.
We saw the number of new adopters be consistent across all best practices which showed that most of the increased adoption came from new implementations that followed most of the best practices as opposed to existing implementations upgrading their webhook services.
This year we analyzed an extra 150 companies from 3 different top startup lists in Fintech, Devtools, and AI to see if we could find any trends between industries as well as differences between startups and established API providers.
In general we saw that the established API providers adopt webhooks at a higher rate and also implement more best practices. This is very logical as the established providers have more resources to invest into offering a better solution and the startups are more likely to be launching MVP (minimum viable product) versions of their webhook services.