At Least One Webhooks

At Least One Webhooks

2026-08-09

This one is a bit technical.

Webhooks are really interesting and necessary in today’s webserver building. I think they are mainly used for asynchronous processing or events. They are transient and immediate, and a good compliment to an API.

There are many use cases for them, I think some of them are more casual, like there might be a webhook when a user opens a marketing email, then your server gets an HTTP call (there isn’t a great standard so sometimes it is a GET or POST) and you need to handle it. There are some more serious cases for webhooks, one that immediately comes to mind is payments, most payment and payment processing are asynchronous and so when you charge a user for something or set up a recurring subscription Stripe (or some other service) will send you a webhook after it is completed successfully.

And this blog is more for the payments style of webhook, if you get a payment, subscription, refund request, or cancellation you need that data in your system. It needs to be ingested 100% of the time. And so hence the title, we need this webhook to fire at least once successfully.

And this is where I have some constructive criticism because I have built a few of these types of systems.

First it, it is pretty hard to develop webhooks locally, you can’t ask stripe to send a POST call to ‘http://localhost:4000’. And so how do you make sure things are working well, formatting properly? It is locked down for a reason and I dont want to be testing on production, there needs to be an easy way to test locally. I think stripe ships with a CLI tool but that is kind of a bandaid for webhooks.

Secondly, if the systems and network are working well then the system works great. But for something like financial transactions there could be some unknown behavior. What happens if our servers go down? Usually they will retry but for how long? What if their servers go down? What is all of AWS goes down for a few hours? If they programmed their webhooks really well they can overcome this but it is a lot of faith you have to have in their systems.

These are the two biggest sticking points for me for webhooks. Any my biggest suggestion for a big company implementing webhooks is to implement great webhooks that at least have all of the retries in place. But a nice complement to webhooks would be some kind of event or webhook API endpoint. Something like this:

GET /api/v1/webhooks?cursor=1&limit=20 200 [ {"id": "unique-abc", ...}, {"id": "unique-def", ...} ]

This type of endpoint will solve both issues, if you are on a local development environment then webhooks wont work at all and you call fallback to only using the API endpoint. Also just in case there is some catastrophic internet event I can get all of the webhooks I missed and reconcile things.

-Gary