Give me /events, not webhooks
I was responsible for Stripe&#x27;s API abstractions, including webhooks and &#x2F;events, for a number of years. Some interesting tidbits:<p>Many large customers eventually had some issue with webhooks that required intervention. Stripe retries webhooks that fail for up to 3 days: I remember $large_customer coming back from a 3 day weekend and discovering that they had pushed bad code and failed to process some webhooks. We&#x27;d often get requests to retry all failed webhooks in a time period. The best customers would have infrastructure to do this themselves off of &#x2F;v1&#x2F;events, though this was unfortunately rare.<p>The biggest challenges with webhooks:<p>- Delivery: some customer timing out connections for 30s causing the queues to get backed up (Stripe was much smaller back then).<p>- Versioning: synchronous API requests can use a version specified in the request, but webhooks, by virtue of rendering the object and showing its changed values (there was a `previous_attributes` hash), need to be rendered to a specific version. This made upgrading API versions hard for customers.<p>There was constant discussion about building some non-webhook pathway for events, but they all have challenges and webhooks + &#x2F;v1&#x2F;events were both simple enough for smaller customers and workable for larger customers.