Hookman: webhooks that follow your branch

Preview deployments are great, until a webhook gets involved. Your app on pr-42.myapp.com needs Stripe events, but Stripe only knows about the URL you gave it. So you paste a new URL into a provider dashboard, or start a tunnel and drop the link in a chat thread, and then you have to remember to change it all back. Multiply that by every open pull request and every provider.

Hookman removes that step. It gives you one permanent webhook endpoint that routes to whichever deployment you choose.

Configure once, route forever

Create a project and Hookman gives you a permanent endpoint:

https://hookman.dev/w/your-org/your-project

You point Stripe, Paddle or any other provider at that URL once, and leave it alone. Hookman sits between your providers and your deployments, and sends each webhook to whichever deployment is currently active. Branches change, the endpoint doesn’t.

Setup takes about three minutes:

1. Create a project. The project slug becomes part of your permanent endpoint.
2. Register your deployments. Tell Hookman where each branch is running, using the dashboard, the CLI or the GitHub Action.
3. Point your provider at Hookman. Update the webhook URL once.
4. Switch branches. Pick the active deployment from the dashboard or the CLI, or let GitHub do it for you.

hookman register \
  --branch feature/checkout \
  --url    https://pr-42.myapp.com/api/webhooks/stripe

hookman switch \
  --project payments \
  --branch  feature/checkout

More than a switch

Once the endpoint sits in the middle, a few other things become easy:

• Routing rules. Match on a header, a query parameter or a field in the JSON body. The first match wins, and anything unmatched falls through to the active deployment.
• Fan-out. Mirror every default-routed webhook to extra deployments, so you can test a refactor against real traffic while production keeps running.
• Replay. Every payload is stored. Re-deliver one to any deployment without triggering a real payment or event again.
• CI registration. The GitHub Action registers a deployment, and its branch rule, on every push, then tears it down when the pull request merges. Scoped API keys keep CI access tight.
• Retries. If your branch is still spinning up, Hookman retries delivery with backoff instead of dropping the webhook. This is on the Pro and Team plans.

Every webhook on the record

Every delivery is logged the moment it happens: the status, the timing, the target and the rule that picked it. You can filter by status, method, time window or routing key, and a wall of 2xx responses tells you it’s working without you writing any logging yourself.

When one goes red, you can open it. The log holds both halves of the exchange: the request exactly as it arrived, and the response your endpoint sent back. Failures are named rather than guessed at: timed out, connection refused, upstream 5xx. If routing was the problem, the log shows which rules were evaluated and why none of them matched.

Once it’s fixed, you don’t have to wait for the provider to send another one. Replay the stored payload to any deployment, pick the target, and a new attempt appears in the log, without a real payment or event firing again.

Logging sits off the hot path. The webhook is answered first and the record is written afterwards, so your provider never waits on us. Routing runs on the Cloudflare edge, with routing latency under 2ms.

Try it

Hookman is free to start, with 1,000 webhooks a month. Have a look at hookman.dev and the docs there. It’s one of the ventures we build and run ourselves at Stellar, and there’s more on its project page.