Forward webhooks to localhost without exposing your app directly
HookNexus gives you a stable public webhook URL, then forwards matching traffic into your local HTTP route with the CLI so you can debug real provider payloads locally.
The typical localhost workflow
- 1. Create an endpoint in HookNexus and copy the public webhook URL into Stripe, GitHub, Shopify, Slack, or another provider.
- 2. Start your local server and run
hooknexus forward --to http://localhost:PORT/PATH. - 3. Watch the dashboard for raw traffic and let the CLI dispatch the same request into your local app.
Example CLI flow
If your local route is listening on port 3000, this is the shortest path from a public webhook URL to a real request inside your app.
hooknexus endpoints create
hooknexus forward ENDPOINT_ID --to http://localhost:3000/api/webhooks/stripeOnce forwarding is active, you can keep the same provider configuration in place and debug against real deliveries instead of rebuilding fake payloads by hand.
Docs to keep open
Why teams choose this flow
- No need to expose a random local port to the internet.
- You can inspect the original request in the dashboard before it reaches your local handler.
- Replay dispatch lets Plus users resend a stored request to an online non-web client.
Related guides
Common localhost problems this solves
- The provider can reach your public endpoint, but your local server never sees the request.
- You are changing tunnel URLs or provider callback settings too often while iterating locally.
- You need to compare the raw request in the dashboard with what your local framework actually parsed.
- You fixed the handler and want another pass with the same saved request instead of triggering the provider again.
When Plus becomes useful
Free is enough to capture traffic and prove the workflow. Plus starts to matter when localhost forwarding and replay become part of your normal development loop instead of a one-off check.
That is usually the point where the team wants to keep a stable public endpoint, retest fixes faster, and stop rebuilding the same provider actions over and over.
When localhost forwarding makes the most difference
- Your app is still local. If your handler is not deployed yet, localhost forwarding is often the fastest way to work with real provider traffic without changing your development setup.
- Request shape matters. Forwarding is especially useful when the exact body, headers, or retries matter and you do not want to recreate them by hand.
- Tunneling feels heavy. If your current loop depends on exposing a random port, updating provider settings, and juggling several tools, this workflow removes that overhead.
FAQ
Do I still need a public webhook URL?
Yes. Providers still need a public URL they can call. HookNexus gives you that stable endpoint first, then forwards matching traffic into localhost.
Can I inspect the request before it hits my local app?
Yes. That is one of the main reasons to use this flow. You can review the request in the dashboard and then let the CLI send it to your local route.
Is this only useful during local development?
Local development is the main use case, but the same approach can also help when you want a stable capture endpoint and a separate downstream client for debugging.