A webhook is an automated message a service sends to your application the instant a specific event happens. Instead of your code repeatedly asking "has anything changed yet?", the service calls a URL you provide and says "this just happened, here are the details." A payment clears, a form is submitted, a build finishes, and your app finds out immediately. Webhooks are how modern services stay in sync in 2026, and they are simpler than the name suggests: it is just an HTTP request, but pointed at you.
The core idea
A normal API call goes one direction: your code asks a service for data. A webhook flips that. The service makes the request to a URL on your server when an event occurs, usually an HTTP POST carrying a JSON payload describing what happened.
Because the service initiates the call, you do not have to keep checking. The information arrives the moment it is relevant. Webhooks are a common building block in how to build a Discord bot in 2026.
Webhook vs polling
| Approach |
How it works |
Trade-off |
| Polling |
You ask repeatedly on a timer |
Wasteful and delayed |
| Webhook |
The service notifies you on the event |
Instant, but you must host an endpoint |
Polling for an event you do not control means either checking too often (wasting requests and hitting rate limits) or too rarely (missing the event for a while). Webhooks remove that compromise: you hear about the event once, right when it happens.
How a webhook flow works
- You register a URL with the service, telling it where to send events.
- An event happens on the service, such as a successful payment.
- The service sends an HTTP POST to your URL with a payload describing the event.
- Your endpoint receives it, verifies it is genuine, and responds quickly with a success status.
- Your app acts on the event, ideally handing the real work to a background job.
// A minimal webhook receiver: accept the POST and acknowledge fast
@app.post("/webhooks/payments")
def handle(payload, signature):
if not verify(signature, payload): // confirm it is really from the sender
return 401
enqueue_job(payload) // do heavy work elsewhere
return 200 // acknowledge immediately
Keeping webhooks secure
Your webhook URL is public, so anyone could send fake events to it. Two defenses matter most.
- Signature verification. Reputable services sign each request with a shared secret. Recompute the signature and compare before trusting the payload. Reject mismatches.
- HTTPS only. Receive webhooks over an encrypted connection so payloads are not exposed in transit.
Many services also include a timestamp so you can reject stale or replayed requests.
How to handle webhooks well
- Respond fast. Acknowledge with a success status quickly; do the real processing in a background queue.
- Make handlers idempotent. Services retry on failure, so the same event may arrive twice. Process it once.
- Log everything. Keep a record of received events for debugging delivery issues.
- Handle retries. Expect duplicates and out-of-order delivery; design for it rather than assuming perfect delivery.
Common mistakes
- Skipping signature checks. An unverified endpoint will happily act on forged events.
- Doing slow work inline. If your handler is slow, the sender may time out and retry, multiplying the load.
- Assuming exactly-once delivery. Real systems retry; without idempotency you double-charge or double-send.
- Exposing the endpoint over plain HTTP. Payloads can contain sensitive data; always use HTTPS.
What to skip
- Heavy processing inside the handler. Acknowledge first, then process asynchronously.
- Building a polling fallback you do not need. If the service offers reliable webhooks with retries, lean on them.
- Trusting the payload blindly. Verify the source every time, no exceptions.
FAQ
What is the difference between a webhook and an API?
With an API, your code initiates the request to fetch data. With a webhook, the service initiates the request to notify you of an event. A webhook is essentially a reverse API call.
Why use a webhook instead of polling?
Polling wastes requests and adds delay because you check on a timer. A webhook delivers the event instantly, the moment it happens, with no repeated checking.
How do I know a webhook is genuine?
Reputable services sign each request with a shared secret. Recompute the signature on your side and compare; reject anything that does not match. Always receive over HTTPS.
Do webhooks get retried if my server is down?
Most services retry failed deliveries on a schedule. That is why your handler should be idempotent, so a retried event is processed only once.
Where to go next
See what a REST API is in 2026, what an API key is in 2026, and what an environment variable is in 2026.