Forem: Henry Hang

How to Test Discord Webhooks with HookCap

Henry Hang — Thu, 02 Apr 2026 01:42:32 +0000

How to Test Discord Webhooks with HookCap

Discord has two distinct webhook concepts that are easy to confuse. Understanding which one you are dealing with determines how you test it.

Incoming webhooks — You POST to a Discord-provided URL to send messages to a channel. Discord is the receiver. You do not need to expose a server.

Bot event webhooks / Interactions endpoints — Discord POSTs to a URL you provide when events happen (slash commands, button clicks, message events). Your server is the receiver.

This guide focuses on the second type: webhooks where Discord sends events to your server. That is the kind that requires a public HTTPS URL and that HookCap helps you test.

Discord Interactions Endpoint

If you are building a Discord app with slash commands, buttons, select menus, or modals, Discord will POST to an Interactions Endpoint URL you register in the Discord Developer Portal. You need to handle these requests on your server.

Discord also uses Gateway (WebSocket) for most bot events. But slash commands and components use the HTTP Interactions endpoint, which is what we will test here.

Step 1: Create a HookCap Endpoint

Go to hookcap.dev, sign up, and create an endpoint. You get a URL like:

https://hookcap.dev/e/your-endpoint-id

Step 2: Register the Endpoint in Discord

Go to the Discord Developer Portal:

Select your application
Under General Information, find the Interactions Endpoint URL field
Paste your HookCap URL
Click Save Changes

Discord will immediately send a verification ping to the URL to confirm it responds correctly. More on this below.

Step 3: Understand the Verification Ping

When you save an Interactions Endpoint URL, Discord sends a PING interaction and expects a PONG response. This is how Discord confirms your endpoint is alive.

Your handler (or HookCap in passthrough mode) must respond to this before Discord accepts the URL.

The ping looks like:

{
  "id": "123456789",
  "type": 1,
  "token": "interaction_token"
}

Your server must respond with:

{
  "type": 1
}

For HookCap's purpose (capturing and inspecting), you can temporarily use Auto-Forward to route the verification ping to your local server so it can respond correctly, then inspect subsequent interactions.

Step 4: Inspect Real Interactions

Once your app is registered, trigger interactions in Discord:

Run a slash command
Click a button in a Discord message your bot sent
Select an option from a select menu

HookCap captures each Discord POST in real time. A typical slash command interaction looks like:

{
  "id": "987654321098765432",
  "type": 2,
  "data": {
    "id": "123456789012345678",
    "name": "ping",
    "type": 1,
    "options": []
  },
  "guild_id": "111111111111111111",
  "channel_id": "222222222222222222",
  "member": {
    "user": {
      "id": "333333333333333333",
      "username": "testuser",
      "discriminator": "0001"
    },
    "roles": []
  },
  "token": "AbCdEfGhIjKlMnOpQrStUvWxYz...",
  "version": 1
}

You can inspect:

type — 1 = PING, 2 = APPLICATION_COMMAND, 3 = MESSAGE_COMPONENT, 4 = APPLICATION_COMMAND_AUTOCOMPLETE, 5 = MODAL_SUBMIT
data.name — the slash command name
data.options — arguments passed to the command
member.user — who triggered it
token — used to respond to the interaction (time-limited)

Verifying Discord Signatures

Discord signs each request with your application's public key using Ed25519. This is different from the HMAC-SHA256 most providers use.

The headers Discord sends:

X-Signature-Ed25519: <hex signature>
X-Signature-Timestamp: <unix timestamp>

Discord signs: timestamp + body (as bytes).

const nacl = require('tweetnacl');

function verifyDiscordSignature(publicKey, signature, timestamp, body) {
  const message = Buffer.concat([
    Buffer.from(timestamp, 'utf-8'),
    Buffer.from(body),
  ]);

  return nacl.sign.detached.verify(
    message,
    Buffer.from(signature, 'hex'),
    Buffer.from(publicKey, 'hex')
  );
}

app.post('/interactions', express.raw({ type: 'application/json' }), (req, res) => {
  const signature = req.headers['x-signature-ed25519'];
  const timestamp = req.headers['x-signature-timestamp'];
  const publicKey = process.env.DISCORD_PUBLIC_KEY; // from Developer Portal

  if (!verifyDiscordSignature(publicKey, signature, timestamp, req.body)) {
    return res.status(401).send('Invalid signature');
  }

  const interaction = JSON.parse(req.body);

  // Handle PING verification
  if (interaction.type === 1) {
    return res.json({ type: 1 });
  }

  // Handle slash commands
  if (interaction.type === 2) {
    const command = interaction.data.name;

    if (command === 'ping') {
      return res.json({
        type: 4, // CHANNEL_MESSAGE_WITH_SOURCE
        data: {
          content: 'Pong! 🏓',
        },
      });
    }
  }

  // Unknown interaction type
  res.status(400).json({ error: 'Unknown interaction type' });
});

You can get your public key from the Discord Developer Portal under General Information → Public Key.

Using HookCap Auto-Forward for Local Testing

The challenge with Discord interactions is the time limit on interaction tokens. You have 3 seconds to respond to an interaction, otherwise Discord shows a "This interaction failed" message to the user.

HookCap Auto-Forward (Pro) solves this cleanly:

Enable Auto-Forward on your HookCap endpoint
Set the forward URL to http://localhost:3000/interactions
Register your HookCap URL in the Discord Developer Portal
Discord sends interactions → HookCap captures + forwards to your local server → response goes back

Because HookCap proxies the request and response in real time, your 3-second response window is preserved. HookCap also stores the full interaction for inspection even after it has been responded to.

Discord → HookCap endpoint → (captured) → Auto-Forward → localhost:3000
                                                                ↓
Discord ← HookCap endpoint ← (forwarded response) ←───────────┘

Testing Without Live Discord (Replay)

Once you have captured a real Discord interaction in HookCap, you can replay it to your local server without going through Discord again.

This is useful for:

Testing edge cases with specific payload structures
Reproducing bugs with exact payloads from production
Running your handler through CI without a real Discord bot configured

When replaying, note that the interaction token in the payload has already expired — you cannot respond to Discord with it. But you can still test your handler's routing, parsing, and internal logic.

Discord Outgoing Webhooks (Sending to Channels)

If you want to test the other direction — your app sending messages to a Discord channel via a Discord webhook URL — you do not need HookCap for the testing itself. But you can use HookCap as a mock Discord endpoint to confirm your app is sending the correct payloads.

Set your webhook URL to a HookCap endpoint instead of a real Discord webhook URL. Your app will POST to HookCap, and you can inspect exactly what would have been sent to Discord.

const fetch = require('node-fetch');

// Instead of real Discord webhook URL, use HookCap for testing
const WEBHOOK_URL = process.env.NODE_ENV === 'test'
  ? 'https://hookcap.dev/e/your-test-endpoint'
  : process.env.DISCORD_WEBHOOK_URL;

await fetch(WEBHOOK_URL, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    content: 'Hello from my app!',
    embeds: [{
      title: 'New Order',
      description: 'Order #1234 has been placed',
      color: 0x57F287,
      fields: [
        { name: 'Customer', value: 'John Doe', inline: true },
        { name: 'Amount', value: '$99.00', inline: true },
      ],
    }],
  }),
});

Inspect the HookCap capture to verify your embed structure, color values, and field layout are correct before sending to real Discord channels.

Common Issues

Endpoint Verification Fails

Discord rejects your Interactions Endpoint URL if the ping fails. Make sure:

Your server is reachable at the URL you provided
It responds to type: 1 with { type: 1 }
Signature verification is correct (Discord verifies its own ping signature)

Using HookCap's Auto-Forward, you can route the ping to your local server so it handles verification while HookCap captures the interaction.

Interaction Token Expired

If you replay a captured interaction and your handler tries to call Discord's API with the old token, the API will return a 401. Use replay for testing handler logic only — do not attempt to respond to Discord with replayed tokens.

Ed25519 Library Missing

Discord requires Ed25519 signature verification. Node.js does not have this built in. Use tweetnacl:

npm install tweetnacl

Or use the discord-interactions package which wraps this:

npm install discord-interactions

const { verifyKeyMiddleware } = require('discord-interactions');

app.post('/interactions',
  verifyKeyMiddleware(process.env.DISCORD_PUBLIC_KEY),
  (req, res) => {
    // Signature already verified by middleware
    const interaction = req.body;
    // ...
  }
);

Summary

Testing Discord webhooks with HookCap:

Interactions Endpoint — Register your HookCap URL in the Discord Developer Portal; Discord will send slash command and component interactions to it
Signature verification — Discord uses Ed25519 (not HMAC-SHA256); use tweetnacl or discord-interactions
Auto-Forward — Forward live interactions to your local server with the 3-second response window intact
Outgoing webhooks — Use HookCap as a mock Discord endpoint to verify payload structure before sending to real channels
Replay — Use captured interactions to test handler logic without re-triggering events in Discord

How to Test Twilio Webhooks with HookCap

Henry Hang — Thu, 02 Apr 2026 01:37:05 +0000

How to Test Twilio Webhooks with HookCap

Twilio sends webhooks for every significant event in its platform: incoming SMS messages, voice call status changes, delivery receipts, WhatsApp messages, and more. If your app responds to any of these, you need a reliable way to capture and inspect real payloads during development.

The core problem is the same as every webhook integration: Twilio needs a public HTTPS URL, but your handler is on localhost. This guide covers using HookCap to solve that during development.

What Twilio Webhooks Are Used For

Twilio webhooks let your server react to events from the Twilio platform:

Webhook type	When it fires
Incoming SMS	A message arrives on your Twilio number
SMS Status Callback	Delivery status changes (sent, delivered, failed)
Incoming voice call	Someone calls your Twilio number
Call Status Callback	A call's state changes (initiated, ringing, answered, completed)
WhatsApp messages	Incoming WhatsApp messages on your number
Verify service events	OTP code sent, check attempts, etc.

Each webhook is an HTTP request Twilio sends to a URL you configure, either in the Twilio Console or via the API.

Step 1: Create a HookCap Endpoint

Go to hookcap.dev, sign up, and create an endpoint. You get a persistent HTTPS URL like:

https://hookcap.dev/e/your-endpoint-id

This URL works immediately — no local server required. Twilio can reach it from anywhere.

Step 2: Configure Twilio to Send to HookCap

For SMS (Messaging Service or Phone Number)

In the Twilio Console:

Go to Phone Numbers → Active Numbers
Select the number you want to configure
Under Messaging Configuration, set the Incoming Message webhook URL to your HookCap endpoint
Set the method to HTTP POST
Save

Alternatively, configure via the Twilio API:

const twilio = require('twilio');
const client = twilio(process.env.TWILIO_ACCOUNT_SID, process.env.TWILIO_AUTH_TOKEN);

await client.incomingPhoneNumbers(process.env.TWILIO_PHONE_NUMBER_SID)
  .update({
    smsUrl: 'https://hookcap.dev/e/your-endpoint-id',
    smsMethod: 'POST',
  });

For Status Callbacks

Status callbacks are configured per-message when you send:

const message = await client.messages.create({
  body: 'Hello from Twilio',
  from: process.env.TWILIO_PHONE_NUMBER,
  to: '+1234567890',
  statusCallback: 'https://hookcap.dev/e/your-endpoint-id',
});

For Voice

In the Twilio Console, go to Phone Numbers → Active Numbers → select your number, then configure the Voice webhook URL.

Step 3: Trigger Events and Inspect Payloads

Send a message to your Twilio number (or call it). HookCap captures the webhook delivery and displays it in real time.

A typical incoming SMS webhook from Twilio looks like:

POST https://hookcap.dev/e/your-endpoint-id

Headers:
  Content-Type: application/x-www-form-urlencoded
  I-Twilio-Signature: AbCdEfGhIjKlMnOpQrStUvWxYz=
  X-Forwarded-For: 3.88.0.0

Body (form-encoded):
  ToCountry=US
  ToState=CA
  SmsMessageSid=SM1234567890abcdef1234567890abcdef
  NumMedia=0
  ToCity=SAN FRANCISCO
  FromZip=10001
  SmsSid=SM1234567890abcdef1234567890abcdef
  FromState=NY
  SmsStatus=received
  FromCity=NEW YORK
  Body=Hello world
  FromCountry=US
  To=+14155551234
  ToZip=94102
  NumSegments=1
  MessageSid=SM1234567890abcdef1234567890abcdef
  AccountSid=ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  From=+12125551234
  ApiVersion=2010-04-01

Note that Twilio webhooks are form-encoded, not JSON. This matters for signature verification.

A status callback looks different — it includes the delivery status:

MessageSid=SM1234567890abcdef
MessageStatus=delivered
ErrorCode=
AccountSid=ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Step 4: Verify the Twilio Signature

Twilio uses a different signature scheme from Stripe and GitHub. Instead of signing just the body, Twilio signs the full request URL plus all POST parameters.

The algorithm:

Take the full URL (including query string)
Append each POST parameter (key + value) in alphabetical order
Sign the result with your Auth Token using HMAC-SHA1
Base64-encode the result

const crypto = require('crypto');

function validateTwilioSignature(authToken, signature, url, params) {
  // Sort params alphabetically and concatenate key+value
  const sortedParams = Object.keys(params)
    .sort()
    .map(key => `${key}${params[key]}`)
    .join('');

  const stringToSign = url + sortedParams;

  const expectedSig = crypto
    .createHmac('sha1', authToken)
    .update(Buffer.from(stringToSign, 'utf-8'))
    .digest('base64');

  // Constant-time comparison
  return crypto.timingSafeEqual(
    Buffer.from(expectedSig),
    Buffer.from(signature)
  );
}

// In your Express handler
app.post('/webhook/twilio/sms', express.urlencoded({ extended: false }), (req, res) => {
  const signature = req.headers['x-twilio-signature'];
  const url = `${req.protocol}://${req.get('host')}${req.originalUrl}`;

  if (!validateTwilioSignature(
    process.env.TWILIO_AUTH_TOKEN,
    signature,
    url,
    req.body
  )) {
    return res.status(403).send('Forbidden');
  }

  const incomingSms = req.body;
  console.log(`SMS from ${incomingSms.From}: ${incomingSms.Body}`);

  // Respond with TwiML
  const twiml = new twilio.twiml.MessagingResponse();
  twiml.message('Got it!');
  res.type('text/xml');
  res.send(twiml.toString());
});

Or use the official Twilio helper library:

const twilio = require('twilio');

app.post('/webhook/twilio', express.urlencoded({ extended: false }), (req, res) => {
  const isValid = twilio.validateRequest(
    process.env.TWILIO_AUTH_TOKEN,
    req.headers['x-twilio-signature'],
    `https://yourdomain.com${req.path}`, // must be the exact URL Twilio used
    req.body
  );

  if (!isValid) {
    return res.status(403).send('Forbidden');
  }

  // Handle the webhook...
});

Important: The URL Must Match Exactly

Twilio signature verification is sensitive to the URL. If Twilio called https://yourdomain.com/webhook/sms but you reconstruct it as http://yourdomain.com/webhook/sms (wrong protocol) or https://yourdomain.com/webhook/sms?foo=bar (extra query param), verification will fail.

Step 5: Use HookCap Auto-Forward to Test Locally (Pro)

With HookCap's Auto-Forward feature, you can forward captured webhooks to your local server — no tunnel setup needed.

In your HookCap dashboard, enable Auto-Forward on your endpoint
Set the forward URL to http://localhost:3000/webhook/twilio
HookCap proxies incoming webhooks from Twilio to your local server in real time

This is more stable than ngrok or localtunnel for Twilio development because:

The HookCap URL stays constant (no need to reconfigure Twilio each time)
You can see both the raw Twilio payload AND your server's response in the HookCap dashboard
If your local server is down, HookCap still captures the webhook for later replay

Common Twilio Webhook Issues

Signature Verification Fails Behind a Proxy

If your server sits behind a load balancer or reverse proxy, the URL your app sees may not match the URL Twilio used. The host, protocol, or port might differ. Fix this by explicitly reconstructing the URL:

// In Express with a trusted proxy
app.set('trust proxy', 1);
const url = `${req.protocol}://${req.hostname}${req.path}`;

Or just hardcode the production webhook URL:

const WEBHOOK_URL = 'https://yourdomain.com/webhook/twilio';
const isValid = twilio.validateRequest(authToken, sig, WEBHOOK_URL, req.body);

Form Encoding vs JSON

Twilio webhooks are application/x-www-form-urlencoded, not JSON. Make sure your framework parses them correctly:

// Correct: use urlencoded parser
app.post('/webhook/twilio', express.urlencoded({ extended: false }), handler);

// Wrong: json parser won't parse Twilio's form-encoded body
app.post('/webhook/twilio', express.json(), handler);

No Response TwiML

For incoming SMS and voice webhooks, Twilio expects a TwiML response. If you return JSON or plain text, Twilio will log an error (though your handler still "worked"). Return valid TwiML:

const twiml = new twilio.twiml.MessagingResponse();
twiml.message('Thank you for your message');
res.type('text/xml').send(twiml.toString());

For status callbacks, a plain 200 OK with no body is fine.

Debugging Workflow

Capture the raw payload in HookCap — See exactly what Twilio sent, including all headers and the form-encoded body
Check the SmsStatus or MessageStatus field — Know what state Twilio thinks the message is in
Replay to your local handler — Use HookCap replay to send the exact captured payload to localhost
Check the Twilio Console error logs — Under Monitor → Logs → Errors, Twilio shows delivery failures with reason codes

HookCap captures the full request including the X-Twilio-Signature header, which you can use to understand what URL Twilio is signing and debug verification failures.

Summary

Testing Twilio webhooks with HookCap:

Create a HookCap endpoint and set it as your Twilio webhook URL
Trigger real events (send SMS, make calls, or use the Twilio Console "Test" feature)
Inspect the form-encoded payload and headers in HookCap
Note: Twilio signs URL + sorted params (not just body) — use the Twilio SDK's validation helper
Use Auto-Forward to proxy live Twilio webhooks to your local server for integrated testing

Webhook vs Polling vs WebSocket: When to Use Each

Henry Hang — Thu, 02 Apr 2026 01:36:30 +0000

Webhook vs Polling vs WebSocket: When to Use Each

Three patterns power most real-time data flows in modern applications: webhooks, polling, and WebSockets. Developers often pick one by habit or familiarity rather than by what the use case actually requires.

This guide explains the real differences, the trade-offs, and the concrete situations where each pattern wins.

The Core Problem

Your application needs to know when something changes in an external system. A payment succeeds. A new GitHub commit is pushed. A user sends a message. A sensor reading exceeds a threshold.

The question is: how does your code find out?

Polling: Your Code Asks

Polling is the simplest mental model. Your application asks the external system at regular intervals: "Has anything changed?"

Your Server                    External API
    |                                |
    |-- GET /payments?after=5m ----->|
    |<---- [] (nothing new) ---------|
    |                                |
    |  [5 minutes pass]              |
    |                                |
    |-- GET /payments?after=5m ----->|
    |<---- [{ id: "pay_123" }] ------|
    |                                |
    |  [process the payment]         |

When Polling Works Well

The external system does not support webhooks — some older APIs are read-only
You control the polling rate — if 1-minute latency is acceptable and the API rate limits are generous
Simple operational requirements — polling is stateless; your process restarts without losing state
Batch data synchronization — syncing data from a source system overnight, where latency does not matter

The Problems with Polling

Latency — You only discover changes at the next poll cycle. If you poll every 5 minutes, your average latency is 2.5 minutes.

Wasted work — Most poll requests return nothing. If your payment succeeds once per hour but you poll every minute, 98% of requests are empty.

Rate limits — Frequent polling burns your API quota. If the API limits you to 1000 requests per day, polling every 2 minutes uses 720 of them.

Scaling poorly — As you add more resources to track (more users, more accounts), the polling load scales linearly.

// Polling example (Node.js)
const POLL_INTERVAL = 5 * 60 * 1000; // 5 minutes

async function pollForNewPayments(lastCheckedAt) {
  const response = await fetch(
    `https://api.payment-provider.com/payments?created_after=${lastCheckedAt}`
  );
  const { payments } = await response.json();

  for (const payment of payments) {
    await processPayment(payment);
  }

  return Date.now();
}

// Simple polling loop
async function startPolling() {
  let lastCheckedAt = Date.now();
  while (true) {
    lastCheckedAt = await pollForNewPayments(lastCheckedAt);
    await sleep(POLL_INTERVAL);
  }
}

Webhooks: The System Tells You

Webhooks flip the direction. Instead of asking repeatedly, you give the external system a URL and it calls you when something happens.

Your Server                    External API
    |                                |
    |  [event occurs]                |
    |                                |
    |<-- POST /webhooks/payment -----|
    |    { type: "payment.success" } |
    |---- 200 OK ------------------->|

When Webhooks Win

Event-driven workflows — fulfilling orders, sending confirmation emails, triggering provisioning
Low-latency requirements — webhooks typically deliver within seconds of the event
High-volume event sources — more efficient than polling for systems generating many events
You have a public-facing server — webhooks require a URL the sender can reach

The Problems with Webhooks

You need a receiver — Your server must be publicly reachable with a stable HTTPS URL. Local development requires extra setup (HookCap, ngrok, Stripe CLI).

Delivery is not guaranteed — Most providers retry on failure, but eventually give up. You must design for missed events.

Out-of-order delivery — Events may arrive in a different order than they occurred. Your handler must be order-independent.

The sender controls the rate — You cannot control how fast events arrive. A burst of 1000 events can overwhelm a handler that assumed a steady drip.

// Webhook handler (Express)
app.post('/webhooks/payment', express.raw({ type: '*/*' }), async (req, res) => {
  // Must verify signature before trusting payload
  if (!verifySignature(req)) {
    return res.status(401).send('Unauthorized');
  }

  const event = JSON.parse(req.body);

  // Acknowledge immediately
  res.json({ received: true });

  // Process async
  await queue.add('payment', { event });
});

WebSocket: A Persistent Two-Way Connection

WebSocket is a protocol, not just a pattern. It establishes a persistent connection between client and server where either side can push messages at any time.

Browser / Client               Server
    |                             |
    |--- WebSocket Handshake ----->|
    |<-- 101 Switching Protocols--|
    |                             |
    |  [connection open]          |
    |                             |
    |<-- { type: "message" } -----|  (server pushes)
    |<-- { type: "presence" } ----|  (server pushes)
    |--- { type: "ping" } ------->|  (client sends)
    |<-- { type: "pong" } --------|
    |                             |
    |  [connection open indefinitely...]

When WebSockets Win

User-facing real-time features — chat, live notifications, collaborative editing, live sports scores
Bidirectional communication — both client and server need to initiate messages
Sub-second latency requirements — WebSocket latency is typically under 100ms
High message frequency — streaming sensor data, live price ticks, game state

The Problems with WebSockets

Connection management — You must handle disconnections, reconnections, and heartbeats
Stateful servers — Load balancers need sticky sessions or a pub/sub layer (Redis) to broadcast to all connected clients
Firewall and proxy issues — Some enterprise networks block non-HTTP protocols or WebSocket upgrades
Not suitable for server-to-server — WebSockets are primarily a browser protocol; server-to-server async events use webhooks instead

// WebSocket server (Node.js with ws)
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', (ws, req) => {
  const userId = getUserFromRequest(req);

  ws.on('message', (message) => {
    const data = JSON.parse(message);
    handleClientMessage(userId, data);
  });

  ws.on('close', () => {
    cleanupUserConnection(userId);
  });

  // Push updates to this client
  ws.send(JSON.stringify({ type: 'connected', userId }));
});

// Push to all connected clients
function broadcastUpdate(event) {
  wss.clients.forEach(client => {
    if (client.readyState === WebSocket.OPEN) {
      client.send(JSON.stringify(event));
    }
  });
}

Side-by-Side Comparison

	Polling	Webhook	WebSocket
Who initiates	Your client	Remote server	Either side
Latency	High (poll interval)	Low (seconds)	Lowest (ms)
Connection	Stateless HTTP	Stateless HTTP	Persistent
Requires public URL	No	Yes	Server needs public URL
Suitable for browsers	Yes	No (servers only)	Yes
Delivery guarantee	You control retries	Provider retries	Application layer
Scales with event volume	Poorly	Well	Depends on infra
Operational complexity	Low	Medium	High

Decision Guide

Use webhooks when:

An external service needs to notify your server about events
You are integrating with Stripe, GitHub, Shopify, Twilio, or any major platform
Latency of a few seconds is acceptable
Events are infrequent relative to polling cost

Use polling when:

The data source does not support webhooks
You are running batch jobs where latency does not matter
You need a simple, stateless integration with no infrastructure to manage

Use WebSockets when:

Users need to see updates in a browser in real time
You need bidirectional communication (not just server-to-client)
Sub-second latency matters
You are building chat, collaborative tools, live dashboards, or multiplayer games

Hybrid Approaches

Real systems often combine patterns:

Webhook + WebSocket: An external event hits your server via webhook. Your server processes it and pushes a notification to connected browser clients via WebSocket.

Stripe --> Webhook --> Your Server --> WebSocket --> Browser

This is the standard pattern for live payment dashboards: Stripe tells your server a payment succeeded (webhook), your server tells the user's browser to update the UI (WebSocket).

Polling + Webhook fallback: Some systems poll as a safety net even when webhooks are configured. If a webhook was missed (delivery failure), the next poll will catch the event.

Long polling: A middle ground between polling and WebSockets. Your client makes an HTTP request, the server holds it open until something happens, then responds. The client immediately makes another request. Lower latency than regular polling, no WebSocket protocol complexity, but higher server resource usage than WebSocket.

Webhooks and HookCap

If you are debugging webhook integrations, HookCap gives you a persistent HTTPS endpoint to capture real webhook deliveries and replay them. You can:

Inspect the exact payload a provider sends without exposing your local server
Replay events to test handler changes without re-triggering events in the provider's system
Use Auto-Forward (Pro) to proxy live webhooks to your local development server

HookCap uses WebSocket internally to push captured events to your dashboard in real time — a practical example of using webhooks and WebSockets together.

Summary

Polling — simple, stateless, high latency, wasteful. Use when the data source does not push.
Webhooks — event-driven, low latency, requires a public receiver. The right choice for server-to-server integrations with modern APIs.
WebSocket — persistent, bidirectional, lowest latency. The right choice for browser real-time features.

Most production systems use all three. The key is matching the pattern to the problem, not defaulting to the one you know best.

Webhook Best Practices: Retry Logic, Idempotency, and Error Handling

Henry Hang — Thu, 02 Apr 2026 01:30:23 +0000

Webhook Best Practices: Retry Logic, Idempotency, and Error Handling

Most webhook integrations fail silently. A handler returns 500, the provider retries a few times, then stops. Your system never processed the event and no one knows.

Webhooks are not guaranteed delivery by default. How reliably your integration works depends almost entirely on how you write the receiver. This guide covers the patterns that make webhook handlers production-grade: proper retry handling, idempotency, error response codes, and queue-based processing.

Understand the Delivery Model

Before building handlers, understand what you are dealing with:

Providers send webhook events as HTTP POST requests
They expect a 2xx response within a timeout (typically 5-30 seconds)
If they do not receive 2xx, they retry on a schedule (often exponential backoff over hours or days)
Most providers have a maximum retry count after which the event is dropped
Some providers allow you to manually retry from their dashboard

Stripe retry schedule:
Attempt 1:  immediate
Attempt 2:  5 minutes
Attempt 3:  30 minutes
Attempt 4:  2 hours
Attempt 5:  5 hours
Attempt 6:  10 hours
Attempt 7:  24 hours
... continues for ~72 hours total

This retry behavior is your safety net -- but only if your handler is idempotent.

Rule 1: Respond Fast, Process Async

Your webhook handler should acknowledge receipt immediately and do the actual work in the background. If you do database writes, call external APIs, or send emails synchronously inside the handler, you risk timing out.

// BAD: synchronous processing risks timeout
app.post('/webhook/stripe', async (req, res) => {
  const event = JSON.parse(req.body);

  if (event.type === 'payment_intent.succeeded') {
    // This could take several seconds
    await fulfillOrder(event.data.object);
    await sendConfirmationEmail(event.data.object.metadata.email);
    await updateInventory(event.data.object.metadata.items);
  }

  res.json({ received: true }); // might never get here if above throws
});

// GOOD: acknowledge immediately, process async
app.post('/webhook/stripe', async (req, res) => {
  const event = JSON.parse(req.body);

  // Queue the work — respond in milliseconds
  await queue.add('stripe-webhook', { event });

  res.json({ received: true }); // always returns 200 fast
});

// Worker processes the queue
queue.process('stripe-webhook', async (job) => {
  const { event } = job.data;
  if (event.type === 'payment_intent.succeeded') {
    await fulfillOrder(event.data.object);
    await sendConfirmationEmail(event.data.object.metadata.email);
    await updateInventory(event.data.object.metadata.items);
  }
});

The queue gives you retry logic, failure visibility, and async processing without blocking the HTTP response.

Rule 2: Make Handlers Idempotent

Since providers retry webhooks, your handler may receive the same event multiple times. You must make your handler safe to run more than once with the same event ID.

Without idempotency, a network blip that causes Stripe to retry a payment_intent.succeeded event could charge a customer twice, create duplicate orders, or send duplicate emails.

Track Processed Event IDs

The simplest approach: store event IDs and skip events you have already processed.

async function handleStripeEvent(event) {
  // Check if we already processed this event
  const existing = await db.query(
    'SELECT id FROM processed_webhooks WHERE event_id = $1',
    [event.id]
  );

  if (existing.rows.length > 0) {
    console.log(`Skipping duplicate event: ${event.id}`);
    return; // idempotent: no-op on duplicate
  }

  // Process the event
  await processEvent(event);

  // Record that we processed it
  await db.query(
    'INSERT INTO processed_webhooks (event_id, processed_at) VALUES ($1, NOW())',
    [event.id]
  );
}

Upsert Instead of Insert

When creating records from webhook data, use upsert (insert-or-update) instead of plain insert:

-- BAD: fails or creates duplicate on retry
INSERT INTO subscriptions (stripe_id, user_id, status, plan)
VALUES ($1, $2, $3, $4);

-- GOOD: idempotent, safe to run multiple times
INSERT INTO subscriptions (stripe_id, user_id, status, plan)
VALUES ($1, $2, $3, $4)
ON CONFLICT (stripe_id)
DO UPDATE SET status = EXCLUDED.status, plan = EXCLUDED.plan;

Use Database Transactions with Idempotency Key

For more complex operations, wrap the idempotency check and business logic in a transaction:

async function handleWebhookIdempotent(eventId, operation) {
  return await db.transaction(async (trx) => {
    // Atomic check-and-insert prevents race conditions on concurrent retries
    const result = await trx.raw(`
      INSERT INTO processed_webhooks (event_id, processed_at)
      VALUES (?, NOW())
      ON CONFLICT (event_id) DO NOTHING
      RETURNING id
    `, [eventId]);

    if (result.rows.length === 0) {
      // Already processed — skip
      return null;
    }

    // Run business logic inside the same transaction
    return await operation(trx);
  });
}

Rule 3: Return the Right HTTP Status Codes

Your response code tells the provider whether to retry. Use it correctly:

Status	Meaning	Provider behavior
200-299	Success	No retry
400	Bad request (your choice not to process)	Providers usually stop retrying
401/403	Unauthorized	Providers usually stop retrying
500-503	Your server error	Provider retries
Timeout	No response in time	Provider retries

The key distinction: use 5xx when the error is transient (database temporarily down, external API timeout) and 4xx when the error is permanent (invalid payload format, unsupported event type).

app.post('/webhook', async (req, res) => {
  let event;

  // Signature verification failure: return 400, don't want retry
  try {
    event = verifyAndParseWebhook(req.body, req.headers);
  } catch (err) {
    return res.status(400).json({ error: 'Invalid signature' });
  }

  // Unknown event type: return 200, don't retry
  if (!supportedEvents.includes(event.type)) {
    return res.status(200).json({ received: true, skipped: true });
  }

  // Queue for async processing, return 200 fast
  try {
    await queue.add(event);
    return res.status(200).json({ received: true });
  } catch (err) {
    // Queue is down: return 503 so provider retries later
    return res.status(503).json({ error: 'Service unavailable' });
  }
});

Rule 4: Handle Out-of-Order Delivery

Providers do not guarantee that webhooks arrive in the order events occurred. A customer.subscription.updated event might arrive before the customer.subscription.created event for the same subscription.

Design your handlers to work regardless of order:

async function handleSubscriptionEvent(event) {
  const sub = event.data.object;

  if (event.type === 'customer.subscription.updated') {
    // Don't assume the subscription already exists in your DB
    await db.query(`
      INSERT INTO subscriptions (stripe_id, status, plan, updated_at)
      VALUES ($1, $2, $3, NOW())
      ON CONFLICT (stripe_id)
      DO UPDATE SET
        status = EXCLUDED.status,
        plan = EXCLUDED.plan,
        updated_at = EXCLUDED.updated_at
      WHERE subscriptions.updated_at < EXCLUDED.updated_at
    `, [sub.id, sub.status, sub.items.data[0].price.id]);
  }
}

The WHERE subscriptions.updated_at < EXCLUDED.updated_at clause handles the case where an older event arrives after a newer one — it will not overwrite newer data with stale data.

Rule 5: Log Everything

Log enough to reconstruct what happened to any webhook event without going back to the provider's dashboard:

const logger = require('pino')();

app.post('/webhook', async (req, res) => {
  const eventId = req.headers['stripe-event-id'] ?? 'unknown';
  const eventType = req.body?.type ?? 'unknown';

  logger.info({ eventId, eventType }, 'Webhook received');

  try {
    await queue.add({ event: req.body });
    logger.info({ eventId, eventType }, 'Webhook queued');
    res.json({ received: true });
  } catch (err) {
    logger.error({ eventId, eventType, err }, 'Failed to queue webhook');
    res.status(503).json({ error: 'Unavailable' });
  }
});

// In your queue worker
queue.process(async (job) => {
  const { event } = job.data;
  logger.info({ eventId: event.id, type: event.type, attempt: job.attemptsMade }, 'Processing webhook');

  try {
    await processEvent(event);
    logger.info({ eventId: event.id }, 'Webhook processed successfully');
  } catch (err) {
    logger.error({ eventId: event.id, err }, 'Webhook processing failed');
    throw err; // let the queue retry
  }
});

Rule 6: Monitor Webhook Health

Failed webhooks are silent by default. Set up monitoring:

Check provider dashboards — Stripe, GitHub, and Shopify all show webhook delivery history. Check them regularly or set up alerts.
Alert on queue depth — If your webhook queue grows, something is wrong upstream.
Track error rates — Log a counter whenever a webhook handler fails. Alert if the error rate spikes.
Set up dead letter queues — Events that fail after all retries should go to a dead letter queue for manual inspection, not disappear silently.

// BullMQ dead letter queue example
const queue = new Queue('webhooks');
const worker = new Worker('webhooks', processWebhook, {
  attempts: 5,
  backoff: { type: 'exponential', delay: 1000 },
});

worker.on('failed', (job, err) => {
  if (job.attemptsMade >= job.opts.attempts) {
    // Move to dead letter queue
    deadLetterQueue.add('failed-webhook', {
      event: job.data.event,
      error: err.message,
      failedAt: new Date().toISOString(),
    });
  }
});

Testing Webhook Handling with HookCap

HookCap makes it easy to test these patterns before production:

Capture real webhook payloads — Point your provider to a HookCap endpoint to collect real events. Inspect headers, body structure, and signature format.
Test retry handling — Use HookCap's replay feature to send the same event to your handler multiple times. Verify that your idempotency logic prevents duplicate processing.
Test error recovery — Replay a captured event to a handler you deliberately break (return 500). Watch how your queue retries it. Fix the handler and replay again.
Simulate out-of-order delivery — Capture a sequence of related events and replay them in reverse order to verify your handler processes them correctly.

The replay feature is especially useful for idempotency testing: you can replay the same event ID dozens of times and confirm your database shows exactly one processed record each time.

Summary

Production webhook handlers need:

Fast acknowledgment — Return 200 immediately, process async
Idempotency — Track event IDs, use upserts, handle duplicate deliveries
Correct status codes — 5xx for transient errors (retry-worthy), 4xx for permanent errors
Order independence — Design DB writes to handle out-of-order events
Comprehensive logging — Log receipt, queuing, processing, and failures
Dead letter queues — Capture events that exhaust all retries

Most webhook failures come down to missing one of these. Add them to your integration checklist before going to production.

How to Secure Webhooks: HMAC Verification and Best Practices

Henry Hang — Thu, 02 Apr 2026 01:30:16 +0000

How to Secure Webhooks: HMAC Verification and Best Practices

Every major webhook provider -- Stripe, GitHub, Shopify, Twilio, Discord -- sends a signature with each webhook delivery. Most developers skip verifying it during development and never add it in production. That is a serious security mistake.

Without signature verification, anyone who discovers your webhook endpoint URL can send fake events to your server: forged payment confirmations, fabricated order updates, spoofed user signups. This guide explains how webhook signatures work and how to implement proper verification in your handler.

Why Webhook Signature Verification Matters

Your webhook endpoint is a public URL. If it accepts unauthenticated POST requests, an attacker can:

Send a fake payment_intent.succeeded event to trigger order fulfillment without paying
Inject malicious payloads that exploit your parsing logic
Flood your endpoint with events to exhaust rate limits or cause downstream issues

Signature verification solves this by proving that a webhook was sent by the service you expected, not a third party.

How HMAC Signatures Work

Most webhook providers use HMAC-SHA256 signatures. Here is the process:

The provider takes the raw request body
Signs it with a secret key using HMAC-SHA256
Sends the signature in a request header (e.g., Stripe-Signature, X-Hub-Signature-256, X-Shopify-Hmac-SHA256)
Your server recomputes the signature using the same secret and compares

If the signatures match, the request is authentic. If they do not match, reject it with a 400 or 401.

Provider Server                    Your Server
     |                                  |
     |  POST /webhook                   |
     |  Body: {"event": "payment..."}   |
     |  Stripe-Signature: t=...,v1=...  |
     |--------------------------------->|
     |                                  |
     |                                  | 1. Extract raw body
     |                                  | 2. Extract signature from header
     |                                  | 3. Compute HMAC-SHA256(secret, body)
     |                                  | 4. Compare computed vs received
     |                                  | 5. Accept or reject

The key word is raw body. If you parse the JSON first and then re-serialize it, the byte-level content may change and the signature comparison will fail. Always sign and verify against the original raw bytes.

Stripe: Signature Verification

Stripe sends a Stripe-Signature header with a timestamp and multiple signatures. The timestamp prevents replay attacks (where an attacker captures a legitimate webhook and re-sends it later).

Stripe-Signature: t=1712345678,v1=5257a869e7ecebeda32affa62cdca3fa51cad7e77a05bd445be62536974f39a

Node.js (Express)

const express = require('express');
const crypto = require('crypto');

const app = express();

// IMPORTANT: use raw body, not parsed JSON
app.post('/webhook/stripe', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['stripe-signature'];
  const webhookSecret = process.env.STRIPE_WEBHOOK_SECRET;

  // Parse the Stripe-Signature header
  const parts = sig.split(',').reduce((acc, part) => {
    const [key, value] = part.split('=');
    acc[key] = value;
    return acc;
  }, {});

  const timestamp = parts.t;
  const receivedSig = parts.v1;

  // Compute the expected signature
  const payload = `${timestamp}.${req.body}`;
  const expectedSig = crypto
    .createHmac('sha256', webhookSecret)
    .update(payload, 'utf8')
    .digest('hex');

  // Constant-time comparison to prevent timing attacks
  const sigBuffer = Buffer.from(receivedSig, 'hex');
  const expectedBuffer = Buffer.from(expectedSig, 'hex');

  if (sigBuffer.length !== expectedBuffer.length || !crypto.timingSafeEqual(sigBuffer, expectedBuffer)) {
    return res.status(400).send('Invalid signature');
  }

  // Check timestamp to prevent replay attacks (5 minute tolerance)
  const now = Math.floor(Date.now() / 1000);
  if (Math.abs(now - parseInt(timestamp)) > 300) {
    return res.status(400).send('Timestamp too old');
  }

  const event = JSON.parse(req.body);
  // Handle event...

  res.json({ received: true });
});

Stripe also provides an official SDK that handles this for you:

const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

app.post('/webhook/stripe', express.raw({ type: 'application/json' }), (req, res) => {
  let event;
  try {
    event = stripe.webhooks.constructEvent(
      req.body,
      req.headers['stripe-signature'],
      process.env.STRIPE_WEBHOOK_SECRET
    );
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }

  // Handle event...
  res.json({ received: true });
});

Python (Flask)

import hmac
import hashlib
import json
from flask import Flask, request, abort

app = Flask(__name__)

@app.route('/webhook/stripe', methods=['POST'])
def stripe_webhook():
    payload = request.get_data()  # raw bytes
    sig_header = request.headers.get('Stripe-Signature', '')
    webhook_secret = os.environ['STRIPE_WEBHOOK_SECRET'].encode('utf-8')

    # Parse the Stripe-Signature header
    parts = dict(part.split('=', 1) for part in sig_header.split(','))
    timestamp = parts.get('t', '')
    received_sig = parts.get('v1', '')

    # Compute expected signature
    signed_payload = f"{timestamp}.".encode('utf-8') + payload
    expected_sig = hmac.new(webhook_secret, signed_payload, hashlib.sha256).hexdigest()

    # Constant-time comparison
    if not hmac.compare_digest(expected_sig, received_sig):
        abort(400, 'Invalid signature')

    event = json.loads(payload)
    # Handle event...

    return {'received': True}

GitHub: Webhook Signature Verification

GitHub uses the X-Hub-Signature-256 header with a simpler format: sha256=<hex_signature>.

app.post('/webhook/github', express.raw({ type: 'application/json' }), (req, res) => {
  const sig = req.headers['x-hub-signature-256'];
  if (!sig) {
    return res.status(401).send('No signature');
  }

  const secret = process.env.GITHUB_WEBHOOK_SECRET;
  const expected = 'sha256=' + crypto
    .createHmac('sha256', secret)
    .update(req.body)
    .digest('hex');

  const sigBuffer = Buffer.from(sig);
  const expectedBuffer = Buffer.from(expected);

  if (sigBuffer.length !== expectedBuffer.length || !crypto.timingSafeEqual(sigBuffer, expectedBuffer)) {
    return res.status(401).send('Invalid signature');
  }

  const payload = JSON.parse(req.body);
  const event = req.headers['x-github-event'];

  // Handle event based on type...
  res.json({ received: true });
});

Go: Generic HMAC Verification

package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/hex"
    "io"
    "net/http"
    "os"
)

func verifyHMAC(body []byte, signature, secret string) bool {
    mac := hmac.New(sha256.New, []byte(secret))
    mac.Write(body)
    expected := hex.EncodeToString(mac.Sum(nil))
    // Use hmac.Equal for constant-time comparison
    return hmac.Equal([]byte(expected), []byte(signature))
}

func webhookHandler(w http.ResponseWriter, r *http.Request) {
    body, err := io.ReadAll(r.Body)
    if err != nil {
        http.Error(w, "Bad request", http.StatusBadRequest)
        return
    }

    sig := r.Header.Get("X-Hub-Signature-256")
    // Strip "sha256=" prefix if present
    if len(sig) > 7 && sig[:7] == "sha256=" {
        sig = sig[7:]
    }

    if !verifyHMAC(body, sig, os.Getenv("WEBHOOK_SECRET")) {
        http.Error(w, "Invalid signature", http.StatusUnauthorized)
        return
    }

    // Process webhook...
    w.WriteHeader(http.StatusOK)
}

Common Mistakes

1. Parsing JSON Before Verification

// WRONG: body-parser changes the raw bytes
app.use(express.json());
app.post('/webhook', (req, res) => {
  // req.body is already parsed — signature check will fail
  verifySignature(JSON.stringify(req.body), sig, secret); // don't do this
});

// CORRECT: keep raw bytes for webhook routes
app.post('/webhook', express.raw({ type: '*/*' }), (req, res) => {
  verifySignature(req.body, sig, secret); // req.body is a Buffer
});

2. String Comparison Instead of Constant-Time

// WRONG: timing attack possible
if (computedSig === receivedSig) { ... }

// CORRECT: constant-time comparison
if (crypto.timingSafeEqual(Buffer.from(computedSig), Buffer.from(receivedSig))) { ... }

Timing attacks are theoretical but real — use constant-time comparison whenever comparing secrets.

3. No Replay Attack Protection

A valid signature only proves the request was sent by the right party. It does not prevent replay: an attacker could capture a legitimate webhook delivery and re-send it hours later. To prevent this, check the timestamp in the signature and reject requests older than a few minutes (typically 5 minutes).

4. Storing the Secret in Source Code

Use environment variables or a secrets manager. Never commit webhook secrets to your repository.

Testing Signature Verification with HookCap

Before going live, use HookCap to inspect and replay webhook deliveries and verify your signature logic handles real payloads correctly.

Create a HookCap endpoint — you get a persistent HTTPS URL
Configure that URL as your webhook destination in Stripe/GitHub/Shopify
Trigger real events from the provider dashboard
Inspect the raw headers, including the signature header
Use HookCap's replay feature to resend a captured payload to your local server

This is especially useful for debugging signature failures — you can see the exact header value the provider sent and compare it against what your code computed.

HookCap's Auto-Forward feature (Pro) also lets you forward captured webhooks directly to localhost, so you can test your local handler with real production payloads without any tunnel setup.

Shopify and Twilio Verification

The same pattern applies to other providers:

Shopify — X-Shopify-Hmac-SHA256 contains a base64-encoded (not hex) HMAC-SHA256 signature:

const crypto = require('crypto');

function verifyShopifyWebhook(body, signature, secret) {
  const expected = crypto
    .createHmac('sha256', secret)
    .update(body)
    .digest('base64');
  return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(signature));
}

Twilio — uses its own X-Twilio-Signature header with a slightly different algorithm. Twilio signs a concatenation of the URL and sorted POST parameters, not just the body. Use the official Twilio Node.js SDK's validateRequest helper.

Summary

Webhook signature verification is not optional for production systems. The steps are always the same:

Read the raw request body — do not parse it first
Extract the signature from the appropriate header
Recompute the HMAC using your webhook secret
Compare using constant-time equality
Check the timestamp if the provider includes one

Each provider has its own header name and sometimes its own signing algorithm details, but the underlying concept is identical. Pick up the SDK when the provider has one — it handles the edge cases for you.

How to Test Webhooks Locally: The Complete Guide

Henry Hang — Tue, 31 Mar 2026 13:07:59 +0000

Every webhook integration hits the same wall during development: the service sending webhooks needs a public HTTPS URL, but your code is running on localhost:3000. Stripe, GitHub, Shopify, Slack — none of them can reach your laptop.

This guide covers every practical approach to solving this, from quick tunnel setups to persistent capture-and-forward workflows.

Originally published at hookcap.dev

The Core Problem

Webhooks are HTTP callbacks. When an event occurs (a payment succeeds, a pull request is opened, an order is placed), the service sends an HTTP POST request to a URL you've configured. That URL must be:

Publicly reachable — the service's servers need to connect to it over the internet
HTTPS — most webhook providers require TLS
Responsive — most providers expect a 2xx response within 3-30 seconds

Your local development server meets none of these requirements.

Approach 1: Tunnel Tools (ngrok, Cloudflare Tunnel, localtunnel)

The most common approach: run a tunnel that creates a public URL pointing to your local server.

ngrok

brew install ngrok
ngrok http 3000

ngrok gives you a URL like https://a1b2c3d4.ngrok-free.app that forwards traffic to localhost:3000.

Pros:

Fast setup — running in under a minute
Supports HTTPS out of the box
Built-in request inspector at http://127.0.0.1:4040

Cons:

URL changes every time you restart (free tier)
No persistent event history — if your server is down when the webhook fires, the event is lost
Your local server must be running to receive events
Free tier has rate limits

Cloudflare Tunnel

brew install cloudflared
cloudflared tunnel --url http://localhost:3000

Pros: Free, no account required. Cloudflare's network is fast.

Cons: Same fundamental limitations as ngrok.

localtunnel

npm install -g localtunnel
lt --port 3000

Open source, free, but less reliable than ngrok or Cloudflare.

When tunnels work well

Tunnels are right when you need something working in 5 minutes or doing a one-off test. They become painful when you restart your tunnel and have to update webhook URLs in every service, or when you miss events because your laptop went to sleep.

Approach 2: Mock Webhook Servers

Manual curl

curl -X POST http://localhost:3000/webhooks/stripe \
  -H "Content-Type: application/json" \
  -H "Stripe-Signature: t=1234567890,v1=abc123..." \
  -d '{
    "id": "evt_test_123",
    "type": "checkout.session.completed",
    "data": { "object": { "amount_total": 2000 } }
  }'

Simple but error-prone — real webhook payloads have dozens of fields.

Provider CLI tools

Stripe CLI:

stripe listen --forward-to localhost:3000/webhooks/stripe
stripe trigger checkout.session.completed

Generates realistic payloads with valid signatures — but only for Stripe. You need a different tool for every provider.

When mocks work well

Good for unit testing individual handler functions. Not a substitute for real webhook deliveries, because real payloads have fields you wouldn't think to include.

Approach 3: Capture and Forward (HookCap)

A different model: use a persistent capture endpoint that records every webhook delivery and optionally forwards it to your local server.

How it works

Create a HookCap endpoint — permanent HTTPS URL like https://hook.hookcap.dev/ep_a1b2c3d4e5f6
Register that URL with your webhook provider (once)
Events are captured — every delivery stored with full headers, body, metadata
Auto-forward to localhost — events forwarded to your local dev server (Pro plan)
Replay any event — one click, any time

Stripe/GitHub/Slack
        │
        ▼
   HookCap endpoint (https://hook.hookcap.dev/ep_...)
        │
        ├── Captures & stores full request
        │
        └── Auto-forwards to localhost:3000/webhooks

Setting up HookCap

Sign in at hookcap.dev and create an endpoint
Register the endpoint URL with your webhook provider
Configure auto-forward (Pro) to your local server: http://localhost:3000/webhooks/stripe
Trigger an event
Event appears in HookCap dashboard and is forwarded to your local server

Why this is different

Your URL never changes. Register once, works indefinitely.

Events are never lost. Server down? Events still captured, replay later.

Replay without re-triggering. No need to make another test payment or push another commit.

Works with every provider. One tool covers Stripe, GitHub, Shopify, Slack.

Comparing the Approaches

	Tunnel (ngrok)	Mock/CLI	HookCap Auto-Forward
Setup time	~1 min	Varies	~2 min
Persistent URL	Paid only	N/A	Always
Event history	No	No	Yes
Works when server is off	No	N/A	Yes (captures + replay)
Replay events	No	Manual	One click
Multi-provider	Separate tunnel	Separate CLI	Single endpoint
Cost	Free limited; $8+/mo	Free	Free tier; Pro $12/mo

Practical Workflows

Workflow 1: Building a new webhook handler

Create a HookCap endpoint and register it in Stripe
Make a test payment
Inspect the captured event — see the exact payload structure
Write your handler based on the real payload (docs sometimes lag)
Enable auto-forward, replay to test
Iterate: modify handler → replay → check response

Workflow 2: Debugging a failing handler

Find the failing event in HookCap history
Replay it to your local server with the debugger attached
Step through with the exact payload that caused the failure
Fix, replay, verify, deploy

Workflow 3: Testing idempotency

Capture a payment_intent.succeeded event
Replay it — first run creates the record
Replay again — should detect duplicate and skip
Check database: only one record

Workflow 4: Multi-provider integration testing

Create three HookCap endpoints (one per provider)
Register each in Stripe, GitHub, Slack
Auto-forward to /webhooks/stripe, /webhooks/github, /webhooks/slack
Test the full flow end-to-end

Signature Verification During Local Testing

Most providers sign their payloads. When replaying from HookCap, original headers are preserved — signatures still valid.

Timestamp staleness: Stripe and Slack reject events older than 5 minutes. For development, extend the tolerance:

if (process.env.NODE_ENV === "development") {
  // 5-day tolerance for replayed events
  event = stripe.webhooks.constructEvent(body, signature, secret, 432000);
} else {
  event = stripe.webhooks.constructEvent(body, signature, secret);
}

Common Mistakes

Not preserving raw request body: Signature verification needs the raw bytes. Mount webhook routes before the JSON parser:

app.post("/webhooks/stripe",
  express.raw({ type: "application/json" }),
  stripeWebhookHandler
);
app.use(express.json()); // after webhook routes

Assuming delivery order: Providers don't guarantee order. Build order-independent handlers.

Not handling retries: A non-2xx response triggers retries for hours. Fix bugs, then process the retry queue.

Testing only the happy path: Use HookCap's history to find real edge cases — null fields, unexpected structures, API version changes.

Getting Started

Sign up at hookcap.dev — free tier available
Create an endpoint
Register it with your webhook provider
Trigger an event and inspect it
Use one-click replay to test your handler
Upgrade to Pro ($12/month) for auto-forward and longer retention

Your HookCap URL is permanent. Register it once, use it for the entire development lifecycle.

Free tier at hookcap.dev — capture, inspect, replay, real-time streaming. Pro $12/month for auto-forward to localhost.

How to Test Slack Webhooks with HookCap

Henry Hang — Tue, 31 Mar 2026 12:50:18 +0000

Slack's platform sends webhooks for everything: messages posted in channels, button clicks in interactive messages, slash command invocations, workflow step callbacks, and app lifecycle events. If you're building a Slack app, you need a reliable way to capture and inspect these events during development.

The challenge is familiar: Slack requires a publicly reachable HTTPS URL, but your app is running on localhost:3000. You need to see the exact payload structure Slack sends, replay events to test edge cases, and iterate quickly without redeploying.

This guide covers using HookCap as your Slack webhook testing tool.

Originally published at hookcap.dev

Types of Slack Webhooks

Slack sends events through several different mechanisms, each with its own payload format:

Type	Where to configure	What it sends
Event Subscriptions	App Settings > Event Subscriptions	Channel messages, reactions, member joins, file uploads
Interactivity	App Settings > Interactivity & Shortcuts	Button clicks, modal submissions, menu selections
Slash Commands	App Settings > Slash Commands	User-typed commands like `/deploy` or `/ticket`
Incoming Webhooks	App Settings > Incoming Webhooks	Outbound only (you send TO Slack) — not relevant here

Event Subscriptions and Interactivity are the two you will work with most. They have different payload structures, different verification requirements, and different response expectations.

Setting Up HookCap for Slack Webhooks

1. Create a HookCap endpoint

https://hook.hookcap.dev/ep_a1b2c3d4e5f6

This URL stays active across sessions. Register it once in your Slack app and it keeps receiving events.

2. Handle the URL verification challenge

When you first enter your HookCap endpoint URL in Slack's Event Subscriptions settings, Slack sends a verification challenge — a POST request with this body:

{
  "token": "Jhj5dZrVaK7ZwHHjRyZWjbDl",
  "challenge": "3eZbrw1aBm2rZgRNFdxV2595E9CY3gmdALWMmHkvFXO7tYXAYM8P",
  "type": "url_verification"
}

Slack expects your endpoint to respond with the challenge value in the response body. HookCap captures this delivery for inspection, but since it responds with a 200 OK and not the challenge string, the verification will not pass directly.

To pass URL verification:

Use HookCap's auto-forward feature (Pro plan) to forward events to your local dev server, which handles the challenge response. Your local handler returns the challenge value, and Slack completes verification. After verification succeeds, all subsequent events continue to flow through HookCap for inspection.

Alternatively, temporarily point Slack to your local handler via a tunnel for the initial verification, then switch the URL to your HookCap endpoint for ongoing development.

3. Configure Event Subscriptions

In your Slack app settings under Event Subscriptions:

Toggle Enable Events on
Enter your HookCap endpoint URL
Subscribe to the bot events you need

Common bot events to subscribe to:

Event	When it fires
`message.channels`	A message is posted to a public channel your bot is in
`message.groups`	A message is posted to a private channel your bot is in
`message.im`	A direct message is sent to your bot
`app_mention`	Your bot is @mentioned in a channel
`reaction_added`	A reaction emoji is added to a message
`member_joined_channel`	A user joins a channel
`channel_created`	A new channel is created

4. Configure Interactivity (if needed)

If your app uses buttons, menus, modals, or shortcuts, go to Interactivity & Shortcuts and enter your HookCap endpoint URL as the Request URL.

Inspecting Slack Event Payloads

Event Subscriptions payload

Every event delivery from Slack follows this envelope structure:

{
  "token": "ZZZZZZWSxiZZZ2yIvs3peJ",
  "team_id": "T061EG9R6",
  "api_app_id": "A0MDYCDME",
  "event": {
    "type": "message",
    "channel": "C2147483705",
    "user": "U2147483697",
    "text": "Hello world",
    "ts": "1355517523.000005",
    "event_ts": "1355517523.000005",
    "channel_type": "channel"
  },
  "type": "event_callback",
  "event_id": "Ev0PV52K25",
  "event_time": 1355517523
}

Interactivity payload

Interactivity payloads arrive as form-encoded POST with a single payload field containing JSON:

{
  "type": "block_actions",
  "user": { "id": "U2147483697", "name": "jsmith" },
  "trigger_id": "13345224609.8534564800.6f8ab1f0f3c9060c0c24a0ef07",
  "actions": [{
    "type": "button",
    "action_id": "approve_request",
    "value": "request_123"
  }]
}

Slash command payload

token=gIkuvaNzQIHg97ATvDxqgjtO
&team_id=T0001
&channel_id=C2147483705
&user_id=U2147483697
&command=%2Fdeploy
&text=production+v1.2.3
&response_url=https%3A%2F%2Fhooks.slack.com%2Fcommands%2F...

Auto-Forward to Your Local Dev Server

With HookCap's auto-forward feature (Pro plan), Slack events are simultaneously captured and forwarded to your local development server.

Set up auto-forward:

Forward URL: http://localhost:3000/slack/events

Now when Slack sends an event:

HookCap captures and stores the full request
HookCap forwards the request to your local server
Your local server processes the event and returns a response

This eliminates the need for a separate tunnel tool.

Slack Request Verification

Slack signs every outgoing request using your app's Signing Secret:

const crypto = require("crypto");

function verifySlackRequest(req, signingSecret) {
  const timestamp = req.headers["x-slack-request-timestamp"];
  const signature = req.headers["x-slack-signature"];

  const fiveMinutesAgo = Math.floor(Date.now() / 1000) - 60 * 5;
  if (parseInt(timestamp) < fiveMinutesAgo) return false;

  const sigBasestring = `v0:${timestamp}:${req.rawBody}`;
  const computed = "v0=" + crypto
    .createHmac("sha256", signingSecret)
    .update(sigBasestring, "utf8")
    .digest("hex");

  return crypto.timingSafeEqual(
    Buffer.from(computed),
    Buffer.from(signature)
  );
}

Important: During replay, the timestamp check will fail because the original timestamp is old. For development, skip it conditionally:

if (process.env.NODE_ENV !== "development") {
  const fiveMinutesAgo = Math.floor(Date.now() / 1000) - 60 * 5;
  if (parseInt(timestamp) < fiveMinutesAgo) return false;
}

Common Slack Webhook Gotchas

3-second timeout: Slack expects a response within 3 seconds. For long operations, respond with 200 OK immediately and process async.

Duplicate delivery: Use event_id for deduplication — Slack may send the same event multiple times.

Bot message loop: Filter out bot messages to avoid infinite loops when your bot posts in subscribed channels:

if (event.bot_id || event.subtype === "bot_message") {
  return res.status(200).send();
}

response_url expiry: Interactivity and slash command response_url values expire after 30 minutes — replaying old events won't be able to POST back to Slack.

Full Development Workflow

Create a HookCap endpoint and configure it in your Slack app settings
Handle URL verification using auto-forward or a temporary tunnel
Trigger events in your Slack workspace
Inspect payloads in HookCap
Write handlers against actual payload shapes
Replay events as you iterate
Test edge cases with specific replayed payloads
Verify signature handling before deploying to production

Free tier available at hookcap.dev — includes capture, inspect, replay, and real-time streaming. Pro plans start at $12/month for auto-forward to localhost.

HookCap vs webhook.site: Which Webhook Testing Tool Is Better in 2026?

Henry Hang — Tue, 31 Mar 2026 06:59:29 +0000

HookCap vs webhook.site: A Direct Comparison

webhook.site is the default answer when someone asks "how do I inspect a webhook." It has been around since 2017 and has 400,000+ monthly users. It is also showing its age in ways that matter for developers who test webhooks regularly, not just once.

HookCap is a newer alternative built around the workflow that repeat webhook debuggers actually follow: capture, inspect, replay, iterate. This post compares the two tools directly so you can decide which fits your workflow.

Full disclosure: we built HookCap. We have tried to be accurate about where webhook.site is genuinely better.

The Core Difference

webhook.site is optimized for one-off inspection. You paste a URL, send a webhook, see what arrived. It is excellent at this.

HookCap is optimized for iterative debugging. You configure a persistent endpoint once, capture webhooks as they arrive in real time, and replay them against your server as you fix bugs. The workflow difference becomes significant after about the third time you need to re-test the same event.

Feature Comparison

Feature	webhook.site	HookCap
Free tier	Yes (7-day URL expiry)	Yes (permanent URLs)
Permanent endpoint URLs	Paid only	All plans, including free
Real-time streaming	Polling (delay)	WebSocket (instant)
One-click replay	No	Yes
Response mocking	Paid only	All plans
Custom domains	Paid	Pro+
Request history	24h free / longer paid	Plan-based
Payload inspection	Yes	Yes
HMAC signature display	Yes	Yes
Pricing (individual tier)	$18/mo	$12/mo

URL Persistence: The Biggest Practical Difference

webhook.site's free tier gives you a URL that expires after 7 days. Every time it expires, you need to go back to your webhook source (Stripe, GitHub, Shopify, whatever) and update the endpoint URL. If you are testing across multiple services, that is multiple places to update.

HookCap gives you permanent URLs on every plan, including free. You configure the endpoint once in your webhook source and never touch it again. The URL stays the same whether you come back tomorrow or in three months.

For one-off testing, URL expiry is not a problem. For any integration you are actively developing over multiple sessions, it adds friction on every return visit.

Real-Time Streaming vs Polling

webhook.site updates through polling — the UI periodically checks for new requests. The delay is usually 1-3 seconds. Not a showstopper, but when you are in a tight debug loop (trigger event → inspect payload → fix handler → trigger again), that delay is present on every iteration.

HookCap streams new requests over WebSocket. When a webhook arrives, it appears in the UI immediately — no refresh, no polling interval. If you have the HookCap dashboard open while running end-to-end tests, new requests appear as they land.

This makes the most difference when you are iterating quickly. Ten debug cycles with a 2-second delay adds 20 seconds. A hundred cycles adds three minutes of waiting that accomplishes nothing.

Replay: The Feature That Changes the Workflow

This is the biggest functional difference between the two tools.

webhook.site has no replay. If you want to re-send a captured webhook to your server, you need to:

Find the captured payload
Copy the full request body
Copy the relevant headers
Construct a curl command with all of that
Run it

That is 60-90 seconds of mechanical work, and you need to repeat it every time you fix a bug and want to re-test.

HookCap has one-click replay. You select a captured request, click Replay, and specify where to send it. HookCap re-sends the original payload with the original headers to your target URL. The whole operation takes about 5 seconds.

Here is the workflow difference in practice:

With webhook.site:

# You need to manually reconstruct this every time
curl -X POST https://your-server.dev/webhook \
  -H "Content-Type: application/json" \
  -H "Stripe-Signature: t=1234567890,v1=abc123..." \
  -H "User-Agent: Stripe/1.0 (+https://stripe.com/docs/webhooks)" \
  -d '{"id":"evt_1234","type":"checkout.session.completed","data":{...}}'

With HookCap:

Click Replay → enter your server URL → done. All original headers are preserved automatically, including signatures.

The replay feature matters most when you are working with complex payloads that are hard to reproduce. Stripe's checkout.session.completed event requires going through an actual checkout to trigger. GitHub's pull_request events require open PRs. Shopify order webhooks require placing test orders. Being able to replay a captured payload saves you from recreating the triggering scenario every time you fix a bug.

Response Mocking

webhook.site offers response mocking on paid plans. You can configure custom status codes, headers, and bodies. This is useful for testing how a webhook sender handles errors — returning 500 to verify Stripe retries, for example.

HookCap offers response mocking on all plans. You configure the response your endpoint returns as part of your endpoint settings. No plan upgrade needed for this.

Pricing

Plan	webhook.site	HookCap
Free	$0 — URLs expire in 7 days	$0 — permanent URLs
Individual	$18/mo	$12/mo
Pro/Business	$49/mo	Pro: $12/mo, Business: metered

webhook.site is more expensive at every paid tier. The gap is largest at the individual tier ($18 vs $12) — a 33% premium for a tool that does not include replay.

When webhook.site Is the Better Choice

To be direct: webhook.site is better for zero-friction, one-off inspection.

The no-signup experience is genuinely good. You go to webhook.site, you get a URL in under 10 seconds, you send your webhook, you see what arrived. You do not create an account, you do not configure anything, you do not remember a password.

If your use case is "I want to see what this service sends for my own understanding" or "I am writing documentation and need to capture one example payload," webhook.site's free tier is the fastest path.

HookCap requires creating an account. That is a real barrier if you only need the tool once.

When HookCap Is the Better Choice

HookCap is the better choice when you are actively developing a webhook integration — building the handler, iterating on business logic, testing edge cases.

The workflow difference compounds over multiple sessions:

Permanent URLs mean you configure once and never update webhook sources again
WebSocket streaming means you see events immediately without polling delays
Replay means you can re-test with any captured payload without reconstructing it from scratch
Response mocking on free tier means you can test error handling without upgrading

If you have been working with webhooks for more than a few weeks, you have probably hit the 7-day URL expiry at least once and done the manual copy-payload-to-curl dance at least a few times. HookCap eliminates both.

Making the Switch

If you are currently using webhook.site and want to try HookCap:

Go to hookcap.dev and create a free account
Create a new endpoint — you get a permanent URL immediately
Update your webhook source to point to the HookCap URL
Use the HookCap dashboard for real-time inspection and replay

If you are debugging a specific integration, the guides for Stripe webhooks and GitHub webhooks walk through the full setup with HookCap.

For a broader comparison that includes Beeceptor, ngrok, and RequestBin, see Webhook Testing Tools Compared (2026).

Summary

Use Case	Better Choice
One-off inspection, no account	webhook.site (free, no signup)
Active webhook integration development	HookCap
Need replay across multiple sessions	HookCap
Need permanent URLs on free tier	HookCap
Need response mocking without paying	HookCap
Testing against local server with debugger	ngrok (either for inspection)

The tools are different in kind, not just in features. webhook.site is optimized for the inspection use case. HookCap is optimized for the debugging use case. If you are debugging — iterating across multiple sessions on a webhook integration — HookCap is the better fit.

How to Replay Webhooks for Faster Debugging

Henry Hang — Tue, 31 Mar 2026 06:54:16 +0000

How to Replay Webhooks for Faster Debugging

When you are building a webhook handler, you run the same cycle over and over: trigger an event, check your handler, find the bug, fix it, trigger again. The problem is that "trigger again" often means going back to Stripe's dashboard, clicking through a checkout flow, or pushing a commit to GitHub just to fire another push event.

This is slow. It breaks your focus. And some events are hard to reproduce on demand — a failed payment, a subscription that just expired, a specific edge-case payload.

Webhook replay solves this. You capture the event once, then replay it as many times as you need against your local server while you iterate on your handler.

What Webhook Replay Actually Does

Replay takes a previously captured webhook delivery and re-sends it to a URL you specify. The re-send includes the original HTTP body and — depending on the tool — the original headers.

This is different from "resending" in a webhook provider's dashboard (like Stripe's "Resend" button). That triggers a new delivery attempt from Stripe's infrastructure, which:

Creates a new delivery record with a new timestamp
Re-runs Stripe's retry logic
Requires network access to your endpoint (your local server needs to be publicly reachable)

Replay from your testing tool is different: it sends the stored payload directly from your browser or the testing service to whatever URL you type in. No round-trip to Stripe. No public URL required. You can target http://localhost:3000/webhooks/stripe directly.

The Development Loop With and Without Replay

Without replay, the typical debug cycle looks like this:

Trigger a real event (complete a test checkout, push a commit, submit a form)
Watch the webhook arrive in your testing tool
Notice your handler returned a 500 or processed the payload incorrectly
Fix the bug in your code
Go back to the event source and trigger the same event again
Wait for delivery

The round-trip to the event source is the bottleneck. Some events are one-click to trigger, but others require specific conditions: a card that declines on the third retry, a subscription that just crossed its trial end date, a GitHub PR that was merged after a specific label was applied. You can not easily manufacture those conditions on demand.

With replay, steps 5 and 6 become: click Replay, enter http://localhost:3000/webhooks/stripe, click Send.

The exact same payload your handler failed on goes to your fixed handler. No event source required.

Setting Up Webhook Replay with HookCap

Step 1: Capture a real delivery

Create an endpoint in HookCap at hookcap.dev. You get a permanent URL like:

https://hook.hookcap.dev/ep_a1b2c3d4e5f6

Configure this URL in your webhook source (Stripe, GitHub, Shopify, Slack, or anything else that sends webhooks). Trigger the event once to capture a real delivery.

HookCap stores the full request: method, headers, body, timestamp, and response status from your endpoint.

Step 2: Inspect the captured payload

Click on the delivery in your dashboard. You will see the raw request body, all headers, and the delivery timeline. This is useful before you replay — check that the payload structure matches what your handler expects.

For Stripe specifically, you will see headers like:

Stripe-Signature: t=1711900800,v1=abc123...
Content-Type: application/json
Stripe-Idempotency-Key: evt_1234...

Step 3: Replay against your local server

In the delivery detail view, click Replay. Enter your local handler URL:

http://localhost:3000/webhooks/stripe

HookCap sends the captured payload to your local server and shows the response. You see the status code and response body immediately.

Step 4: Iterate

Fix your handler, click Replay again. Repeat until the response is 200 {"received": true} (or whatever your handler returns on success).

The payload does not change between replays. You are testing the same bytes your handler failed on originally.

Handling Signature Verification During Replay

Most webhook providers sign their payloads. Stripe uses HMAC-SHA256 with a signing secret per endpoint. When you replay to localhost, your handler will try to verify the Stripe-Signature header — but the signature was computed for the original HookCap endpoint URL, not your local server.

There are two practical approaches:

Option A: Disable signature verification in development

Add a flag to skip verification when running locally:

if (process.env.NODE_ENV !== 'development') {
  const sig = req.headers['stripe-signature'];
  event = stripe.webhooks.constructEvent(rawBody, sig, process.env.STRIPE_WEBHOOK_SECRET);
} else {
  event = JSON.parse(rawBody);
}

This is the fastest option during active development. Make sure the NODE_ENV check is solid before you deploy.

Option B: Use a test signing secret

In Stripe, your test mode webhook endpoint has its own signing secret (whsec_test_...). When replaying to your local server, you can use the Stripe CLI to forward events and apply your local signing secret — or use HookCap's re-sign feature to attach a valid signature for your local secret before replay.

Either approach means your handler runs through the full verification path, giving you higher confidence that it will work in production.

What to Replay and When

Replay is most valuable in three scenarios:

1. Debugging a broken handler

Your handler failed. You have the exact payload that caused the failure. Fix the code, replay, verify. This is the core use case.

2. Testing edge cases

Some events are hard to trigger on demand:

invoice.payment_failed — requires a card that declines on retry, not just on the first attempt
customer.subscription.deleted — requires a subscription to be cancelled, which may involve billing cycles
GitHub's pull_request closed event after a merge — requires an actual merge

Capture these once when they occur naturally, then replay them anytime.

3. Regression testing

When you change your webhook handler, replay a set of known-good deliveries to verify nothing broke. This is not a substitute for unit tests, but it is a fast sanity check before you ship.

Replay vs. Resend: When to Use Each

	Replay (testing tool)	Resend (provider dashboard)
Destination	Any URL, including localhost	Must be a registered, publicly reachable endpoint
Network access	Not required for source	Required
Signature	Original or re-signed	New signature from provider
Speed	Instant	Depends on provider retry queue
Use case	Active development	Reproducing a missed delivery in production

Use replay when you are developing. Use the provider's resend when you need to reprocess a specific delivery that failed in production.

A Note on Idempotency

If you replay the same event multiple times, your handler will receive the same event ID each time. Your handler should be idempotent — processing the same event twice should not create duplicate records or charge a customer twice.

Test this deliberately during development:

Replay an event that creates a database record
Replay it again
Verify you have one record, not two

The pattern is simple:

// Check if we already processed this event
const existing = await db.query(
  'SELECT id FROM processed_events WHERE event_id = $1',
  [event.id]
);

if (existing.rows.length > 0) {
  return res.status(200).json({ received: true }); // Already handled
}

// Process the event, then mark it as handled
await processEvent(event);
await db.query(
  'INSERT INTO processed_events (event_id, processed_at) VALUES ($1, NOW())',
  [event.id]
);

Replay makes idempotency testing easy because you can hit the same endpoint with the same event ID as many times as you want.

Why This Matters More Than You Think

The debugging loop improvement is real but understated. Replay does not just save the time of re-triggering events — it changes what is possible to test.

Hard-to-reproduce events stop being hard to test once you have captured them. Edge cases that only appear under specific business conditions become repeatable. And because you are testing against your actual handler with the actual payload that caused the failure, there are no surprises when you deploy.

This is the difference between a capture tool and a debugging tool. Capture shows you what arrived. Replay lets you work with what you captured.

Start capturing and replaying webhooks for free at hookcap.dev. Replay is available on all plans.

Why Real-Time Matters for Webhook Testing

Henry Hang — Tue, 31 Mar 2026 06:54:14 +0000

Why Real-Time Matters for Webhook Testing

Most webhook testing tools work the same way under the hood: your browser asks the server "any new requests?" every few seconds, and the server responds with whatever it has. This is polling. It works, but it introduces a gap between when a webhook arrives and when you see it.

That gap costs you more time than you think.

The polling tax

Here is what a typical webhook debugging session looks like with a polling-based tool:

Configure your webhook source to point at a test URL
Trigger an event (complete a test checkout, push a commit, update an order)
Switch to the testing tool's tab
Wait. Refresh. Wait. See the request appear.
Inspect the payload, find the issue
Fix your handler code
Trigger the event again
Wait. Refresh. Wait.

Steps 4 and 8 take 2-5 seconds each on most tools. That does not sound like much, but you are not doing this once. A typical webhook integration involves dozens of iterations: verifying payload structure, testing error handling, checking signature validation, handling edge cases. Across 30 debug cycles, you spend 2-5 minutes just waiting for the UI to catch up.

Worse, polling creates uncertainty. When you trigger an event and nothing appears after a few seconds, you are left wondering: did the webhook not fire? Is there a configuration error? Or has the poll just not run yet? You end up refreshing manually, which breaks your focus.

What real-time actually means

Real-time webhook testing uses WebSocket connections instead of polling. Here is the difference:

Polling: Your browser sends HTTP requests to the server at fixed intervals (e.g., every 3 seconds). Each request asks "anything new?" The server responds with any requests that arrived since the last poll.

WebSocket streaming: Your browser opens a persistent connection to the server. When a webhook arrives, the server pushes it to your browser immediately. No interval. No delay. No request/response cycle.

The practical effect: a webhook appears in your dashboard the instant it hits the endpoint. By the time you switch browser tabs after triggering a Stripe test event, the payload is already there waiting for you.

How this changes the debugging workflow

The shift from polling to real-time is less about the raw seconds saved and more about how it changes your focus:

No more "did it work?" moments. When webhooks appear instantly, you never question whether the event fired. If you trigger a checkout and nothing shows up, you know immediately that there is a configuration problem, not a timing issue. This eliminates an entire category of false debugging.

Tighter iteration loops. The debug cycle shortens from "trigger, switch tabs, wait, refresh, inspect" to "trigger, switch tabs, inspect." This might sound like a small difference, but shorter loops mean you stay in flow. You are thinking about the payload structure, not about whether the UI has refreshed yet.

Reliable event ordering. With polling, if multiple webhooks arrive between polls, they all appear at once. With streaming, each one appears as it arrives, in order. This matters when you are testing event sequences -- for example, verifying that payment_intent.created arrives before payment_intent.succeeded.

A practical example: debugging Stripe webhooks

You are building a subscription billing flow. When a customer completes checkout, Stripe sends a checkout.session.completed webhook. Your handler needs to provision the customer's account.

With a polling-based tester, the cycle looks like this:

Go to Stripe's dashboard, trigger a test checkout event
Switch to the webhook testing tool
Wait 3-5 seconds for the poll to fire
Inspect the payload -- notice the customer field is nested differently than you expected
Update your handler code
Trigger another test event from Stripe
Wait again for the poll

With real-time streaming (WebSocket):

Go to Stripe's dashboard, trigger a test checkout event
Switch to HookCap -- the payload is already displayed
See the customer field structure immediately
Update your handler code
Trigger another event -- it appears instantly

The improvement is subtle in a single cycle but significant across an entire integration. You stay focused on the problem (parsing the payload correctly) rather than on the tooling (did my request arrive yet?).

Now add replay to this workflow. After you fix your handler, you do not even need to go back to Stripe. Click the replay button, send the captured checkout.session.completed payload to http://localhost:3000/webhooks/stripe, and verify your fix immediately. The round-trip drops from minutes to seconds.

Why most tools still use polling

Polling is simpler to build and cheaper to run. A polling endpoint is a standard HTTP GET request -- stateless, cacheable, works behind any CDN. WebSocket connections are persistent, stateful, and require infrastructure that can hold many concurrent connections open.

This is a legitimate engineering tradeoff, and for tools where real-time feedback is not critical, polling is fine. But webhook debugging is an interactive, iterative process. When you are actively developing and testing, the responsiveness of your tools directly affects your productivity.

HookCap uses WebSocket streaming because we believe webhook testing falls squarely in the "real-time matters" category. The trade-off is more complex infrastructure on our side -- we run on Cloudflare Workers with Durable Objects to manage WebSocket connections at the edge -- but the result is a fundamentally smoother debugging experience.

Try it yourself

The difference between polling and real-time is easier to feel than to describe. Create a free endpoint on hookcap.dev, open the dashboard, and send a request:

curl -X POST https://hookcap.dev/w/your-endpoint-id \
  -H "Content-Type: application/json" \
  -d '{"event": "test", "timestamp": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"}'

Watch the request appear the instant you hit Enter. Then imagine doing that 30 times in a debugging session, and compare it to refreshing a page every time.

The seconds add up. The focus you preserve adds up more.

What Is a Webhook? A Developer's Guide to Understanding and Debugging Webhooks

Henry Hang — Tue, 31 Mar 2026 06:49:01 +0000

What Is a Webhook? A Developer's Guide to Understanding and Debugging Webhooks

If you have integrated with any modern API -- Stripe, GitHub, Shopify, Twilio, Slack -- you have encountered webhooks. They are one of those concepts that seems simple on the surface but causes real headaches when something goes wrong. This guide explains what webhooks are, how they work, and (more importantly) how to debug them when they break.

What Is a Webhook?

A webhook is an HTTP request that a service sends to your server when something happens.

That is it. There is no special protocol, no binary format, no persistent connection. A webhook is a plain HTTP POST request with a JSON body, sent from one server to another.

The difference between a webhook and a normal API call is direction. With a normal API, your code calls the service. With a webhook, the service calls your code.

Polling vs. Webhooks

Without webhooks, you would need to repeatedly ask a service "did anything change?" This is called polling.

POLLING (you ask repeatedly):

Your Server                    Stripe
    |--- Any new payments? ------>|
    |<-------- Nope. -------------|
    |                             |
    |--- Any new payments? ------>|
    |<-------- Nope. -------------|
    |                             |
    |--- Any new payments? ------>|
    |<-- Yes, here is one. ------|

WEBHOOKS (they tell you):

Your Server                    Stripe
    |                             |
    |    (customer pays)          |
    |                             |
    |<-- POST /webhooks/stripe ---|
    |    {payment: details}       |
    |--- 200 OK ---------------->|

Webhooks are more efficient. You do not waste resources asking repeatedly, and you learn about events as soon as they happen instead of on your next poll interval.

How Webhooks Work

The flow for setting up and receiving webhooks has four steps:

Step 1: Register your endpoint. You tell the service "send events to this URL." This is usually done through a dashboard or API call.

# Example: registering a webhook endpoint with Stripe
curl https://api.stripe.com/v1/webhook_endpoints \
  -u sk_test_your_key: \
  -d url="https://yourapp.com/webhooks/stripe" \
  -d "enabled_events[]"="payment_intent.succeeded"

Step 2: The event occurs. A customer makes a payment, a pull request is opened, an order is placed -- whatever the triggering event is.

Step 3: The service sends an HTTP POST to your URL. The request body contains details about the event.

POST /webhooks/stripe HTTP/1.1
Host: yourapp.com
Content-Type: application/json
Stripe-Signature: t=1679012345,v1=abc123...

{
  "id": "evt_1N2abc",
  "type": "payment_intent.succeeded",
  "data": {
    "object": {
      "id": "pi_3N2xyz",
      "amount": 2000,
      "currency": "usd",
      "status": "succeeded"
    }
  }
}

Step 4: Your server processes the event and responds with 200 OK. The service considers the delivery successful if it receives a 2xx response within a timeout window (typically 5-30 seconds).

Anatomy of a Webhook Request

A webhook is just an HTTP request, but most services include these elements:

Component	Purpose	Example
Method	Always POST	`POST /webhooks/stripe`
Content-Type	Usually JSON	`application/json`
Body	Event payload	`{"type": "payment.succeeded", ...}`
Signature header	Verify authenticity	`Stripe-Signature: t=...,v1=...`
Event type	What happened	`payment_intent.succeeded`
Timestamp	When it happened	`"created": 1679012345`

Common Failure Modes (And How to Fix Them)

Here is where things get practical. These are the webhook failures developers hit most often, in rough order of frequency.

1. Signature Verification Failure

Most services sign webhook payloads using HMAC-SHA256 or a similar scheme. Your server must verify this signature to confirm the request actually came from the service and was not tampered with.

Symptoms: Your server returns 400/401, or you reject the webhook in code. The service shows "delivery failed" in its dashboard.

Common cause: Your verification code is checking the parsed JSON body instead of the raw request body. Even a single byte difference (like whitespace changes from JSON parsing) invalidates the signature.

// WRONG: body is already parsed
app.use(express.json());
app.post('/webhook', (req, res) => {
  verify(req.body, signature); // req.body is an object, not raw bytes
});

// RIGHT: use raw body for verification
app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  verify(req.body, signature); // req.body is a Buffer
});

Fix: Make sure your webhook route receives the raw request body. In Express, use express.raw() on the webhook route. In other frameworks, check their docs for accessing the raw body before parsing.

2. Endpoint Not Reachable

Symptoms: The service reports delivery failure. Your server logs show nothing (no request received).

Causes:

Your server is not running or not publicly accessible
DNS is not configured correctly
Firewall or security group is blocking incoming requests
TLS certificate is expired or invalid (most services require HTTPS)
The URL path is wrong (trailing slash matters for some frameworks)

Debugging steps:

# Test your endpoint manually
curl -X POST https://yourapp.com/webhooks/stripe \
  -H "Content-Type: application/json" \
  -d '{"test": true}'

# Check DNS resolution
dig yourapp.com

# Check TLS certificate
openssl s_client -connect yourapp.com:443 -servername yourapp.com

3. Timeout

Symptoms: The service reports delivery failed, but your server did receive and process the request. You see the webhook in your logs, but the service shows a failure.

Cause: Your handler took too long to respond. Most services have a timeout between 5 and 30 seconds. If your handler does heavy work (database writes, external API calls, sending emails) synchronously before responding, you will hit this.

Fix: Acknowledge the webhook immediately with a 200 response, then process asynchronously.

# Python/Flask example
@app.route('/webhook', methods=['POST'])
def handle_webhook():
    event = verify_signature(request)

    # Queue for async processing
    task_queue.enqueue(process_event, event)

    # Respond immediately
    return '', 200

4. Duplicate Delivery

Symptoms: Your system processes the same event multiple times. A customer gets charged twice, or receives duplicate emails.

Cause: Webhook senders retry on failure (or perceived failure -- see timeouts above). If your first handler execution timed out but still completed, the retry delivers the same event again.

Fix: Make your handler idempotent. Store the event ID and check for duplicates before processing.

app.post('/webhook', async (req, res) => {
  const event = verifyAndParse(req);

  // Check if we already processed this event
  const existing = await db.query(
    'SELECT id FROM processed_events WHERE event_id = $1',
    [event.id]
  );

  if (existing.rows.length > 0) {
    return res.status(200).json({ already_processed: true });
  }

  // Process and record
  await processEvent(event);
  await db.query(
    'INSERT INTO processed_events (event_id, processed_at) VALUES ($1, NOW())',
    [event.id]
  );

  res.status(200).json({ received: true });
});

5. Payload Parsing Errors

Symptoms: Your server returns 500. Logs show JSON parse errors or missing fields.

Causes:

The webhook body is not valid JSON (rare, but happens with some services that send form-encoded data)
Your code expects fields that do not exist for this event type
The payload structure changed (API version mismatch)

Fix: Validate the payload structure before accessing nested fields. Use optional chaining or explicit checks.

// Fragile
const email = event.data.object.customer.email;

// Defensive
const email = event?.data?.object?.customer?.email;
if (!email) {
  console.warn('No customer email in event', event.id);
}

A Debugging Workflow That Works

When a webhook integration is not working, follow this order:

1. Verify the webhook is being sent. Check the sender's dashboard. Stripe, GitHub, Shopify, and most services have a webhook delivery log that shows every attempt, the response code, and the response body.

2. Verify the webhook reaches your server. Check your server logs for the incoming request. If there is nothing, the problem is network-level (DNS, firewall, TLS, routing).

3. Capture and inspect the raw payload. Use a webhook testing tool to see exactly what is being sent. This eliminates guesswork about the payload structure.

Tools for this:

webhook.site -- instant throwaway URL, no signup needed
HookCap (hookcap.dev) -- real-time streaming with replay capability
ngrok localhost:4040 -- inspect requests passing through the tunnel

Point the webhook sender at your testing URL temporarily, trigger an event, and examine the full request: method, headers, body, timing.

4. Test signature verification in isolation. Take the raw payload and headers from step 3 and run them through your verification code locally. This isolates whether the problem is in signature verification or downstream processing.

5. Test your handler with a known-good payload. Use curl or a replay tool to send the captured payload directly to your local server:

curl -X POST http://localhost:3000/webhooks/stripe \
  -H "Content-Type: application/json" \
  -H "Stripe-Signature: t=1679012345,v1=..." \
  -d @captured-payload.json

6. Check for non-obvious failures. If the webhook is received and your server returns 200, but the expected side effects are not happening, check:

Is the event type handled in your switch/case? Unhandled types often silently succeed.
Is the database write failing silently?
Is there an async processing queue, and is it running?

Retries and Reliability

Most webhook senders implement retry logic. If your server does not return a 2xx response, the sender will try again. Typical retry schedules:

Stripe: Up to 3 days, with exponential backoff (first retry after ~1 hour)
GitHub: 1 retry after a short delay
Shopify: 19 retries over 48 hours

This means your server does not need to have 100% uptime to receive all webhooks -- short outages are covered by retries. But your handler must be idempotent (see failure mode #4 above), because retries mean the same event can be delivered more than once.

Security Considerations

Three rules for handling webhooks securely:

Always verify signatures. Never skip signature verification, even in development. A webhook endpoint is a publicly accessible URL. Without verification, anyone can send fake events to it.
Do not trust the payload blindly. After verifying the signature, fetch the referenced resource from the API to confirm its state. This protects against replay attacks and stale data.
Use HTTPS. Webhook payloads often contain sensitive data (customer emails, payment amounts, order details). Always use HTTPS endpoints, and reject any service that sends webhooks over plain HTTP.

Summary

Webhooks are simple in concept (one server sends an HTTP POST to another) but require care in implementation. The main things to get right:

Verify signatures using the raw request body
Respond quickly (200 OK), process asynchronously
Make handlers idempotent to survive retries
Use a capture tool during development to inspect payloads before writing handler code
Follow the debugging workflow: sender logs, then network, then payload, then handler

Once the integration is solid, webhooks are one of the most reliable and efficient patterns for connecting services. The debugging is a one-time cost that pays off for the lifetime of the integration.

Webhook Testing Tools Compared (2026): webhook.site vs HookCap vs Beeceptor vs RequestBin vs ngrok

Henry Hang — Tue, 31 Mar 2026 06:48:58 +0000

Webhook Testing Tools Compared (2026)

Testing webhooks should be simple: get a URL, point a service at it, see what arrives. In practice, different tools make different tradeoffs around persistence, real-time inspection, replay capabilities, and pricing. This comparison covers the five most-used options in 2026 and where each one fits best.

Full disclosure: we built HookCap, so we obviously have a bias. We have tried to be fair. Where a competitor is genuinely better for a use case, we say so.

Quick Comparison

Feature	webhook.site	HookCap	Beeceptor	RequestBin (Pipedream)	ngrok
Free tier	Yes (generous)	Yes (limited)	Yes (limited)	Yes (limited)	Yes (limited)
Permanent URLs	Paid only	All plans	Paid only	No	No (tunnel URLs rotate)
Real-time streaming	Polling	WebSocket	Polling	Polling	N/A (local server)
Payload inspection	Yes	Yes	Yes	Yes	Via local server
One-click replay	No	Yes	No	No	N/A
Response mocking	Paid	Yes	Yes	Via workflow	N/A
Local tunneling	No	No	No	No	Yes (core feature)
Custom domains	Paid	Pro+ plans	Paid	No	Paid
Team features	No	Business plan	No	Yes (Pipedream)	Yes
Request history	24h free / longer paid	Plan-based	Limited	Limited	No persistence

Pricing Comparison (March 2026)

Plan Tier	webhook.site	HookCap	Beeceptor	RequestBin	ngrok
Free	$0 (generous limits)	$0 (basic)	$0 (50 req/day)	$0 (limited)	$0 (limited)
Individual/Starter	$18/mo	$12/mo	$12/mo	$19/mo (Pipedream)	$8/mo
Pro/Team	$49/mo	$29/mo	$39/mo	$29/mo	$20/mo
Enterprise	$69/mo	$79/mo	Custom	Custom	$40+/mo

Note: Prices may change. Check each tool's website for current pricing.

Detailed Breakdown

webhook.site

What it is: The original webhook testing tool. Paste a URL, send requests to it, see what arrives. Has been around since ~2017 and dominates search rankings for "webhook testing."

Pros:

Zero-friction free tier. No signup required. You get a URL in seconds.
Handles high volume well. The infrastructure is mature.
Supports custom actions (email notifications, scripting) on paid plans.
XPath/JSONPath extraction on paid plans.
Massive community familiarity. Almost every webhook tutorial references it.

Cons:

No real-time streaming. The UI polls for new requests, so there is a slight delay.
No replay functionality. If you want to re-send a captured webhook to your server, you need to manually copy the payload and use curl.
Free tier URLs expire. You need a paid plan for persistent endpoints.
No WebSocket support for live-tailing.
UI has not changed much in years. Functional but dated.

Best for: Quick, one-off webhook inspection when you just need to see what a service sends. The free tier's zero-signup experience is genuinely unbeatable for throwaway testing.

HookCap

What it is: Webhook testing tool focused on real-time inspection, replay, and debugging workflows. Built on Cloudflare Workers and WebSocket streaming.

Pros:

Real-time WebSocket streaming. Webhooks appear instantly in the UI without page refresh or polling.
One-click replay. Captured webhooks can be re-sent to any URL (local dev server, staging, etc.) with a single click. This saves meaningful time when iterating on webhook handler logic.
Permanent endpoint URLs on all plans, including free. No more reconfiguring webhook sources after a URL expires.
Response mocking. Configure your endpoint to return specific status codes, headers, and bodies. Useful for testing how a webhook sender handles failures.
Cheaper than most alternatives at each tier ($12/$29/$79).

Cons:

No local tunneling. If you need to expose localhost directly, you need ngrok or a similar tunnel alongside HookCap.
Newer product. Smaller community and fewer integrations compared to webhook.site.
Free tier has lower limits than webhook.site's free offering.
No built-in scripting/workflow engine (RequestBin/Pipedream has this).

Best for: Developers who test webhooks regularly and want faster debugging cycles. The replay and real-time features pay off when you are iterating on webhook handler code, not just inspecting payloads once.

Beeceptor

What it is: Mock API and webhook interceptor. Beeceptor focuses on API mocking with webhook capture as one of its features.

Pros:

API mocking is a first-class feature. You can create mock REST APIs with custom routes and responses, not just webhook endpoints.
Local tunneling (SubdomainProxy) available on paid plans.
Clean, modern UI.
Good for frontend developers who need to mock backends during development.

Cons:

Free tier is very limited (50 requests/day).
No real-time streaming.
No replay functionality.
Webhook capture feels secondary to the API mocking focus.
Limited request history on free/lower plans.

Best for: Developers who need API mocking AND webhook testing in one tool. If your primary need is mocking API responses for frontend development, Beeceptor does that better than the webhook-focused tools.

RequestBin (Pipedream)

What it is: RequestBin was the original webhook capture tool. It was acquired by Pipedream and is now integrated into Pipedream's workflow automation platform.

Pros:

Part of Pipedream's larger platform. If you want to do something with captured webhooks beyond inspection (transform, forward, trigger workflows), Pipedream's workflow engine is powerful.
Good for building webhook-driven automations.
Generous free tier for Pipedream's broader platform.
SDKs and integrations for hundreds of services.

Cons:

Overkill if you just want to inspect webhooks. The Pipedream platform is large and has a learning curve.
RequestBin URLs are not permanent on the free tier.
No real-time WebSocket streaming.
The standalone "RequestBin" experience has been absorbed into the larger Pipedream product, which can be confusing.
Not optimized specifically for webhook debugging (no replay, no response mocking in the bin itself).

Best for: Teams who want webhook capture as part of a larger automation pipeline. If you are building workflow automations triggered by webhooks, Pipedream is the right tool. If you just want to debug a webhook integration, it is more tool than you need.

ngrok

What it is: ngrok is a tunneling tool that exposes your local server to the internet. It is not a webhook testing tool per se, but it is widely used for webhook development.

Pros:

Your actual server processes the webhook. No separate inspection tool needed -- use your own logging and debugger.
Works with any webhook source, not just specific integrations.
Supports TCP, TLS, and HTTP tunnels.
Request inspection UI available at localhost:4040.
Good for development beyond webhooks (sharing local sites, testing mobile apps against local APIs).

Cons:

URLs change on every restart (free tier). Paid plans offer stable subdomains.
No persistent history. Once the tunnel is down, captured requests are gone.
No replay functionality.
Your local server must be running to receive webhooks. If it crashes or you restart it, you miss events.
Adds network complexity (traffic routes through ngrok's servers).
Not useful for inspecting webhooks from services you do not control the handler for.

Best for: Developers who want to test webhooks against their actual running server with a real debugger attached. Especially useful during the final stages of integration when you want to verify your complete handler logic, not just inspect payloads.

Feature Deep-Dive: What Actually Matters

Real-Time Updates

When you are actively debugging, the difference between real-time WebSocket streaming and polling matters more than you would expect. With polling, you send a webhook, wait, manually refresh or wait for the poll interval, then see the result. With WebSocket streaming, the webhook appears the instant it arrives.

This sounds minor, but when you are iterating through a cycle of "trigger event, see payload, fix handler, trigger again," even a 2-3 second polling delay adds up across dozens of iterations.

Real-time streaming: HookCap (WebSocket)
Polling: webhook.site, Beeceptor, RequestBin
N/A: ngrok (your local server handles it directly)

Replay

Replay means re-sending a previously captured webhook payload to a URL of your choice. This is useful when:

You fix a bug in your webhook handler and want to re-test with the same payload
You want to test how your handler deals with a specific edge case payload you captured earlier
You need to re-process a webhook that failed in staging

Without replay, you need to either re-trigger the event in the source system (which may not be easy for complex scenarios like subscription renewals or dispute resolutions) or manually copy the payload and use curl.

Built-in replay: HookCap
No replay: webhook.site, Beeceptor, RequestBin, ngrok

Response Mocking

Response mocking lets you configure what your test endpoint returns (status code, headers, body). This is useful for testing how webhook senders handle errors. For example:

Return a 500 to see if Stripe retries correctly
Return a slow response to test timeout behavior
Return specific response bodies for services that expect acknowledgment payloads

Response mocking: HookCap, Beeceptor, webhook.site (paid)
Via workflow: RequestBin/Pipedream
N/A: ngrok (your server controls the response)

Persistence

URL and request persistence determines whether your test setup survives between sessions.

Permanent URLs: HookCap (all plans), webhook.site (paid), Beeceptor (paid)
Session-based URLs: webhook.site (free), RequestBin (free)
Tunnel-lifetime URLs: ngrok (free; stable subdomain on paid)

Decision Guide

Here is how to choose, based on your actual situation:

"I just need to quickly see what a webhook sends."
Use webhook.site's free tier. No signup, instant URL, zero friction. This is the fastest path for one-off inspection.

"I am building a webhook integration and will debug it repeatedly over days/weeks."
Use HookCap. Permanent URLs mean you configure your webhook source once. Real-time streaming and replay save time across many debug cycles.

"I need to test my actual webhook handler code with a debugger."
Use ngrok. It exposes your real local server, so you can set breakpoints and step through your handler.

"I need API mocking plus webhook capture."
Use Beeceptor. Its mock API features are more developed than the webhook-focused tools.

"I want to build automations triggered by webhooks."
Use Pipedream (RequestBin). Its workflow engine handles webhook-triggered automations that go way beyond inspection.

"I need multiple tools."
Most developers end up using a combination. A common setup: ngrok for local debugging with breakpoints + HookCap or webhook.site for payload inspection and testing retry behavior. These tools complement each other more than they compete.

Summary

There is no single "best" webhook testing tool. The right choice depends on your workflow:

webhook.site remains the easiest entry point with its zero-signup free tier
HookCap offers the best debugging workflow with real-time streaming, replay, and competitive pricing
Beeceptor is strongest when you need API mocking alongside webhook capture
RequestBin/Pipedream is the right call when webhooks feed into larger automations
ngrok is irreplaceable when you need to debug your actual handler code locally

Try the free tiers. You will know within 20 minutes of real use which tool fits your workflow.