[Atomic Glue](atomicglue.co)
BACKEND
Home › Glossary › Backend· 454 ·

Webhook

\\web-hook\\n.
Filed underBackendApisMarketing Automation
In brief · quick answer

A webhook is an HTTP callback that sends real-time data from one system to another when a specific event occurs. It is a server-to-server push mechanism, the opposite of polling.

§ 1 Definition

A webhook is an automated message sent by one system to another over HTTP when a specific event happens. Unlike polling, where the consumer repeatedly checks for new data, webhooks push data immediately. This makes webhooks more efficient and enables real-time integrations. Webhooks are sometimes called 'reverse APIs' because the server sends requests to the client's endpoint (the webhook URL) instead of the client calling the server. The sender registers a URL endpoint where it will POST data when events occur. When the event fires, the sender serializes the event data (usually as JSON) and sends an HTTP POST request to the registered URL. The receiver must acknowledge receipt with a 2xx HTTP status code. Webhooks are widely used for payment notifications (Stripe, PayPal), CI/CD events (GitHub, GitLab), messaging (Slack, Discord), and CRM integrations.

§ 2 How Webhooks Work

The flow is straightforward. The consumer provides a URL endpoint to the provider. The provider stores this URL and validates it (often with a challenge-response handshake called URL verification). When an event occurs (a payment succeeds, a PR is merged, a deploy completes), the provider sends an HTTP POST request to the registered URL with a JSON body containing event data. The consumer processes the data and returns a 200 OK to acknowledge. If the provider receives a non-2xx response or a timeout, it retries with exponential backoff, typically for 24-72 hours. This simple mechanism replaces polling with instant push notifications.

§ 3 Webhook Security

Security is the hardest part of webhooks. Since webhook URLs are public endpoints, anyone could discover them and send fake events. Defenses include: 1) Signing the payload with a shared secret using HMAC (SHA-256). The consumer verifies the signature before processing. 2) Verifying the sender's IP address against published address ranges. 3) Requiring HTTPS to prevent interception. 4) Using webhook secrets rotated regularly. 5) Implementing idempotency keys to deduplicate events. Stripe, GitHub, and Slack all use HMAC signing. Never process an unsigned webhook payload without verification.

§ 4 Webhooks vs Polling vs WebSockets

Webhooks are one of three real-time data patterns. Polling (the consumer repeatedly asks the provider for new data) is simpler to implement but wastes resources and introduces latency. Webhooks (the provider pushes data when events occur) are efficient and real-time but require an accessible endpoint and robust error handling. WebSockets (persistent bi-directional connection) are best for high-frequency, low-latency, bidirectional communication like chat and live collaboration. The right choice depends on your latency requirements, whether the communication is one-way or two-way, and your infrastructure capabilities.

§ 5 Note

Common misunderstanding: Webhooks are not APIs. An API is a request-response interface that the client calls. A webhook is a callback that the server calls when something happens. Webhooks are sometimes called 'reverse APIs' for this reason. Another misconception: webhooks are fire-and-forget. They are not. The sender expects a 2xx acknowledgment and retries on failure. Your webhook handler must be idempotent because the same event may be delivered multiple times.

§ 6 In code

```javascript
// Express webhook receiver
import express from 'express';
import crypto from 'node:crypto';

const app = express();

app.post('/webhooks/stripe', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['stripe-signature'];
  const secret = process.env.STRIPE_WEBHOOK_SECRET;

  try {
    const event = stripe.webhooks.constructEvent(req.body, sig, secret);
    
    if (event.type === 'payment_intent.succeeded') {
      console.log('Payment succeeded:', event.data.object.id);
    }
    
    res.json({ received: true });
  } catch (err) {
    res.status(400).send(`Webhook Error: ${err.message}`);
  }
});

app.listen(3000);
```

§ 7 Common questions

Q. Are webhooks secure?
A. They can be, with HMAC signature verification, HTTPS, IP whitelisting, and idempotency handling. Never process unsigned webhooks in production.
Q. What happens if my webhook endpoint is down?
A. The provider retries with exponential backoff, typically for 24-72 hours. If it still fails, the event is usually logged and you need to handle it manually or via a webhook dashboard.
Q. Can webhooks send data both ways?
A. No. Webhooks are one-directional push notifications. For bidirectional real-time communication, use WebSockets or Server-Sent Events (SSE).
Key takeaways
  • Webhooks are HTTP callbacks that push data from one system to another when events occur.
  • They replace polling with immediate push, reducing latency and wasted requests.
  • Security requires HMAC signature verification, HTTPS, and idempotent handlers.
  • Webhooks are one-directional; use WebSockets for bidirectional real-time communication.
How Atomic Glue helps

Atomic Glue builds webhook integrations for payment processing (Stripe), CI/CD (GitHub), messaging (Slack), and CRM systems. We design robust webhook handlers with HMAC verification, idempotent processing, and retry logic. If your application needs to react to external events in real time, webhooks are our standard integration pattern. Webhook engineering is part of our broader Web Development services. Get in touch to set up your integrations.

Get in touch
# Webhook

A webhook is an HTTP callback that sends real-time data from one system to another when a specific event occurs. It is a server-to-server push mechanism, the opposite of polling.

Category: Backend (also: Apis, Marketing Automation)

Author: Atomic Glue Development Team

## Definition

A webhook is an automated message sent by one system to another over HTTP when a specific event happens. Unlike polling, where the consumer repeatedly checks for new data, webhooks push data immediately. This makes webhooks more efficient and enables real-time integrations. Webhooks are sometimes called 'reverse APIs' because the server sends requests to the client's endpoint (the webhook URL) instead of the client calling the server. The sender registers a URL endpoint where it will POST data when events occur. When the event fires, the sender serializes the event data (usually as JSON) and sends an HTTP POST request to the registered URL. The receiver must acknowledge receipt with a 2xx HTTP status code. Webhooks are widely used for payment notifications (Stripe, PayPal), CI/CD events (GitHub, GitLab), messaging (Slack, Discord), and CRM integrations.

## How Webhooks Work

The flow is straightforward. The consumer provides a URL endpoint to the provider. The provider stores this URL and validates it (often with a challenge-response handshake called URL verification). When an event occurs (a payment succeeds, a PR is merged, a deploy completes), the provider sends an HTTP POST request to the registered URL with a JSON body containing event data. The consumer processes the data and returns a 200 OK to acknowledge. If the provider receives a non-2xx response or a timeout, it retries with exponential backoff, typically for 24-72 hours. This simple mechanism replaces polling with instant push notifications.

## Webhook Security

Security is the hardest part of webhooks. Since webhook URLs are public endpoints, anyone could discover them and send fake events. Defenses include: 1) Signing the payload with a shared secret using HMAC (SHA-256). The consumer verifies the signature before processing. 2) Verifying the sender's IP address against published address ranges. 3) Requiring HTTPS to prevent interception. 4) Using webhook secrets rotated regularly. 5) Implementing idempotency keys to deduplicate events. Stripe, GitHub, and Slack all use HMAC signing. Never process an unsigned webhook payload without verification.

## Webhooks vs Polling vs WebSockets

Webhooks are one of three real-time data patterns. Polling (the consumer repeatedly asks the provider for new data) is simpler to implement but wastes resources and introduces latency. Webhooks (the provider pushes data when events occur) are efficient and real-time but require an accessible endpoint and robust error handling. WebSockets (persistent bi-directional connection) are best for high-frequency, low-latency, bidirectional communication like chat and live collaboration. The right choice depends on your latency requirements, whether the communication is one-way or two-way, and your infrastructure capabilities.

## Note

Common misunderstanding: Webhooks are not APIs. An API is a request-response interface that the client calls. A webhook is a callback that the server calls when something happens. Webhooks are sometimes called 'reverse APIs' for this reason. Another misconception: webhooks are fire-and-forget. They are not. The sender expects a 2xx acknowledgment and retries on failure. Your webhook handler must be idempotent because the same event may be delivered multiple times.

## In code

## Common questions
Q: Are webhooks secure?
A: They can be, with HMAC signature verification, HTTPS, IP whitelisting, and idempotency handling. Never process unsigned webhooks in production.
Q: What happens if my webhook endpoint is down?
A: The provider retries with exponential backoff, typically for 24-72 hours. If it still fails, the event is usually logged and you need to handle it manually or via a webhook dashboard.
Q: Can webhooks send data both ways?
A: No. Webhooks are one-directional push notifications. For bidirectional real-time communication, use WebSockets or Server-Sent Events (SSE).

## Key takeaways

## Related entries


Last updated June 2026. Permalink: atomicglue.co/glossary/webhook

Schedule a call

30 min · Video call

1
Date
2
Time
3
Details