· 6 min read

Introducing HookCap: A Better Way to Test Webhooks

By HookCap Team

Introducing HookCap: A Better Way to Test Webhooks

If you have built anything that receives webhooks, you know the drill: open a testing tool, get a temporary URL, paste it into your webhook provider’s settings, trigger an event, refresh the page to see if anything arrived, squint at the payload, and repeat. When the URL expires tomorrow, do it all over again.

We built HookCap because this workflow has not meaningfully improved in years, despite webhooks becoming the backbone of modern integrations. Stripe, GitHub, Shopify, Twilio — nearly every service pushes events via webhooks, yet the tools for testing them still rely on disposable URLs and polling-based UIs.

Here is what we changed.

The problem with current webhook testing tools

Most webhook testers work the same way. You get a temporary URL, point your webhook source at it, and refresh the page to see captured requests. This has three friction points that compound over time:

URLs expire. Free tiers on most tools give you URLs that last hours or days. Every time a URL expires, you need to reconfigure your webhook source. If you are testing a Stripe integration, that means navigating Stripe’s dashboard, pasting a new URL, and waiting for verification. Multiply this by every service you integrate with.

Polling delays. When you send a webhook, most tools do not show it immediately. The UI polls for new requests on an interval. The delay is usually 2-5 seconds, which sounds trivial until you are iterating through dozens of send-inspect-fix cycles in an afternoon.

No replay. You capture a webhook payload, find a bug in your handler, fix it, and then… need to re-trigger the original event. For simple events that is easy. For complex scenarios — a Stripe subscription renewal, a Shopify order with specific line items, a GitHub deployment status change — re-triggering the exact same event is tedious or impossible.

What we built

HookCap is a webhook testing tool designed around the debugging workflow, not just payload inspection. It runs on Cloudflare Workers at the edge, so it is fast globally, and it addresses the three problems above directly.

Permanent webhook URLs

Every HookCap endpoint gets a permanent URL that does not expire, even on the free plan. Create an endpoint, configure your webhook source once, and it works until you delete it.

https://hookcap.dev/w/my-stripe-test

No more reconfiguring webhook sources after a URL expires. Set it and forget it.

Real-time WebSocket streaming

When a webhook hits your endpoint, it appears in your dashboard instantly via WebSocket. No polling, no refresh button, no delay.

This changes the debugging rhythm. You trigger an event in Stripe’s test mode, and by the time you switch to the HookCap tab, the request is already there — method, headers, body, query parameters, everything. The feedback loop tightens from “trigger, wait, refresh, inspect” to “trigger, inspect.”

One-click replay

Every captured request has a replay button. Click it, enter a target URL (your local dev server, a staging endpoint, a colleague’s machine), and HookCap re-sends the exact request — same method, headers, and body.

This is particularly useful when:

  • You fix a bug in your handler and want to re-test with the exact payload that caused it
  • You are onboarding a teammate and want to show them real webhook payloads
  • You need to replay a failed webhook through your staging environment

No more copying payloads into curl commands manually.

Response mocking

Configure what your endpoint returns to the webhook sender. Set a custom status code, headers, and response body.

This lets you test how webhook senders handle failures without touching your application code. Return a 500 to verify Stripe retries correctly. Return a 200 with a specific acknowledgment body for services that expect one. Add artificial delay to test timeout behavior.

# Your endpoint is configured to return a 503
# Stripe sends a webhook, gets a 503, and retries later
# You can see the retry behavior in real-time

A concrete example

Say you are integrating Stripe’s checkout.session.completed webhook. Here is the workflow with HookCap:

1. Create an endpoint

Log in, click “New Endpoint,” name it stripe-checkout. You get:

https://hookcap.dev/w/abc123

2. Configure Stripe

Paste the URL into Stripe’s webhook settings. Select the checkout.session.completed event.

3. Trigger a test event

In Stripe’s dashboard, use their test mode to trigger a checkout completion.

4. Inspect in real-time

Switch to HookCap. The request is already there. Expand it to see the full payload:

{
  "type": "checkout.session.completed",
  "data": {
    "object": {
      "id": "cs_test_...",
      "payment_status": "paid",
      "customer_email": "[email protected]"
    }
  }
}

5. Build your handler

Write your handler locally. When you want to test it, hit the replay button and point it at http://localhost:3000/webhooks/stripe. The exact Stripe payload hits your local server.

6. Iterate

Find a bug? Fix it and replay the same request. No need to go back to Stripe and trigger another test event. The captured payload is there for as many replays as you need.

What is in the free plan

HookCap’s free tier includes:

  • 5 endpoints with permanent URLs
  • 3,000 requests per month
  • 1 day of request history retention
  • Real-time streaming, replay, and response mocking

No credit card required. The free tier is designed for individual developers testing webhook integrations on side projects or during initial development.

For teams and heavier usage:

  • Pro ($12/mo): 25 endpoints, 10,000 requests/month, 30-day retention
  • Team ($29/mo): 100 endpoints, 100,000 requests/month, 90-day retention
  • Business ($79/mo): Unlimited endpoints, 1M requests/month, 365-day retention

What HookCap is not

HookCap is not a tunneling tool. It does not expose your localhost to the internet like ngrok does. If you need to test your webhook handler with a real debugger and breakpoints, you still want a tunnel tool for that. HookCap and ngrok complement each other: use HookCap to capture and inspect payloads, and replay them to your local server when you are ready to debug handler logic.

HookCap is also not a workflow automation platform. If you want to transform webhooks and forward them to other services as part of a pipeline, tools like Pipedream are built for that. HookCap is focused on the testing and debugging phase of webhook development.

What is next

We are building HookCap in the open and shipping features based on real usage. On the roadmap:

  • Team collaboration — shared endpoints and request history across your team
  • Webhook forwarding — automatically forward captured requests to a URL in real-time
  • CLI tool — manage endpoints and tail requests from your terminal
  • Provider-specific guides — step-by-step tutorials for Stripe, Shopify, GitHub, and more

Get started

Create a free account and set up your first endpoint in under a minute.

Get started at hookcap.dev/register

If you have been using webhook.site, RequestBin, or curl scripts to test webhooks, give HookCap a try. The permanent URLs and replay alone will save you time on your first integration.