Webhooks sound like a scary advanced concept, but they're quite simple.
A webhook is just an event that's sent to your server by an external service when something happens.
For example, here at Boot.dev we use Stripe as a third-party payment processor. When a student makes a payment, Stripe sends a webhook to the Boot.dev servers so that we can unlock the student's membership.
HTTP POST request to https://api.boot.dev/stripe/webhook (that's not the real URL, but you get the idea)That's it! The only real difference between a webhook and a typical HTTP request is that the system making the request is an automated system, not a human loading a webpage or web app. As such, webhook handlers must be idempotent because the system on the other side may retry the request multiple times.
Idempotent, or "idempotence", is a fancy word that means "the same result no matter how many times you do it". For example, your typical POST /api/chirps (create a chirp) endpoint will not be idempotent. If you send the same request twice, you'll end up with two chirps with the same information but different IDs.
Webhooks, on the other hand, should be idempotent, and it's typically easy to build them this way because the client sends some kind of "event" and usually provides its own unique ID.
We recently rolled out a new feature called "Chirpy Red". It's a membership program, and members of "Chirpy Red" get pretty incredible features: like the ability to edit chirps after posting them. But that's beside the point...
Chirpy uses "Polka" as its payment provider. They send us webhooks whenever a user subscribes to Chirpy Red. We need to mark users as Chirpy Red members when we receive these webhooks.
{
"event": "user.upgraded",
"data": {
"user_id": "3311741c-680c-4546-99f3-fc9efac2036c"
}
}
Polka uses the response code to know whether or not the webhook was received successfully. If the response code is anything other than 2XX, they'll retry the request.
Run and submit the CLI tests.