Webhook Testing

Test webhook integrations from services like Stripe, GitHub, Shopify, and Twilio against your local development server — no deployment needed.

The problem

Third-party services need a public URL to send webhooks. During development, your server is on localhost. You could deploy to a staging server every time you change a handler, or you could just open a tunnel.

Quick setup

# Your webhook handler is on port 3000
nullbore open --port 3000 --ttl 2h
# ✓ https://a7f3bc.tunnel.nullbore.com → localhost:3000

Now paste https://a7f3bc.tunnel.nullbore.com/webhooks/stripe into Stripe's webhook settings.

Stable URLs: Use --name stripe-test (Dev+) to get https://stripe-test.yourname.nullbore.com — the same URL every time. Pro plans can also use a custom domain (stripe-test.tunnel.yourcompany.com).

With daemon mode

If you're testing webhooks regularly, add it to your config:

# ~/.config/nullbore/config.toml
server = "https://tunnel.nullbore.com"
api_key = "nbk_your_key"

[[tunnels]]
name = "stripe-test"
port = 3000

nullbore daemon --detach
# Tunnel stays up, reconnects automatically

Inspect requests

Check what the webhook sender is actually sending:

nullbore requests stripe-test
# Shows recent request metadata: method, path, headers, body preview

You can also see request logs in the dashboard.

Tips

  • Set a sensible TTL — 2 hours is usually enough for a testing session. Daemon mode auto-renews if you need it longer.
  • Check signatures — services like Stripe and GitHub sign webhook payloads. Make sure your handler validates signatures even during testing.
  • Use daemon mode for regular testing — avoids re-opening tunnels and updating webhook URLs every session.

Works great with

  • Stripe webhooks
  • GitHub webhooks (push, PR, release events)
  • Shopify webhooks
  • Twilio callbacks
  • Slack event subscriptions
  • Any service that sends HTTP callbacks