Webhooks: Don't Call Us, We'll Call You
A webhook is an automated HTTP callback from a service to your app when an event happens. Instead of polling for updates, the service calls you. This is how Stripe signals a payment or GitHub a commit.
WHY IT EXISTS: To avoid inefficient polling. Constantly asking an API 'is there new data?' is wasteful for both the client and the server, creating unnecessary network traffic and load. Webhooks solve this by inverting the communication model, enabling event-driven architecture between web services.
THE MENTAL MODEL: Think of it as giving a service your phone number and asking them to call you when your package is delivered, instead of you calling them every five minutes to ask 'is it here yet?'. The webhook is your phone number (a URL). The call is the HTTP POST request. The package delivery is the event, like a payment processing.
HOW IT WORKS: First, you register a URL in a source application's settings. This URL points to a server you control. When a specific event happens (like a 'git push'), the source application sends an HTTP POST request to your registered URL. This request's body contains a payload, usually in JSON format, with details about the event. Your server receives this request, parses the payload, and takes action.
WHEN TO USE IT: Use webhooks for asynchronous, event-driven workflows. Three common scenarios: first, receiving real-time notifications, like a new sale from an e-commerce platform. Second, triggering CI/CD pipelines when code is pushed to a repository. Third, synchronizing data between two different systems, like updating a CRM when a new user signs up.
WHEN NOT TO USE IT: Don't use webhooks if you need a synchronous response. If you need to immediately confirm that an action was processed and get data back in the same HTTP request, a standard API call is better. They are also not a good fit for high-volume, low-importance events that could overwhelm your endpoint.
ONE CANONICAL EXAMPLE: A GitHub webhook triggering a Jenkins build. You configure your GitHub repository to send a webhook to your Jenkins server's URL whenever a push is made to the main branch. When a developer pushes code, GitHub sends a POST request with a JSON payload containing commit details. Jenkins receives this and automatically starts a new build job. The developer gets feedback without manual intervention.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.