Test Webhooks with n8n, Zapier & Make Locally

Automation platforms like n8n, Zapier, and Make are excellent at consuming webhooks — a provider fires an event, the platform catches it, and a workflow runs. The trouble starts when you want to build and test those workflows against real traffic before you ship them. A self-hosted n8n instance on localhost:5678 can't be reached from Stripe or GitHub. Zapier and Make live in the cloud and only speak to public URLs. So you end up copy-pasting sample payloads, guessing at header shapes, and discovering the mismatch only after you flip to production.

The fix is a stable public ingress that forwards live events to your machine. That's what Relayers does: it gives you a permanent webhook URL, routes events with JQ filters, reshapes payloads with transformations, and tunnels the result straight to a port on your laptop — original body and headers untouched.

What you'll build

One public endpoint fans out to your local n8n, Make, or a plain HTTP handler — so you can develop automations offline against real events, then point production at the cloud automation URL.

Prerequisites

• The Relayers desktop app installed (download it) and a free account.
• The relayers CLI on your PATH.
• A self-hosted n8n (default localhost:5678) or any local service that accepts POST requests.
• A provider or automation platform that can send an HTTP request to a URL.

1Create an endpoint in Relayers

Open the desktop app, go to Endpoints, and create one. You'll get a public ingest URL shaped like:

https://api.relayers.app/v1/webhooks/wep_abc123

Hit Copy to grab it, and use Send test to fire a sample payload so you can confirm the endpoint is live before wiring anything else up.

2Point your automation (or a provider) at the endpoint

You have two directions here, and both use the same endpoint.

Receive from an automation platform. All three tools can POST to an arbitrary URL: Zapier's Webhooks by Zapier, Make's HTTP module, and n8n's HTTP Request node. Point any of them at your Relayers URL to drive your local handler with data an automation produces. This is the fastest way to test a local service that's downstream of a cloud workflow.

Receive a provider webhook and forward it to local n8n. More often you want the opposite: catch a real provider event and feed it into a workflow you're still building. Register the Relayers URL as the webhook destination in your provider's dashboard (Stripe, GitHub, Shopify, etc.). Relayers becomes the stable front door; your n8n Webhook trigger node stays on localhost where you can iterate on it.

One caution: Zapier, Make, and n8n outbound requests usually send plain JSON with no signature. Add a shared-secret header so your local side can reject anything that didn't come through your pipeline (more on that below).

3Forward events to localhost

Authenticate the CLI once, then start a tunnel:

relayers login
relayers listen --forward localhost:5678

In the endpoint's Rules, set the destination to the tunnel so matching events land on localhost:5678. Now every event that hits your public URL is delivered to your self-hosted n8n's webhook path in real time. Trigger a test event and watch it arrive in the Events view — click any event to open the payload inspector and see exactly what was delivered.

4Route and filter with JQ

A single endpoint can feed several local automations. In Rules, each rule is a JQ filter over the request body, and the first match wins — so order matters, and you can reorder rules by dragging them.

Route subscription events to your n8n instance and everything else to a second local service:

# Rule 1 — destination: tunnel → localhost:5678 (n8n)
.type | startswith("customer.subscription")

# Rule 2 — destination: tunnel → localhost:3000 (fallback handler)
true

Because rules evaluate top to bottom, put your specific filters first and a catch-all (true) last. This lets you build separate n8n workflows per event type without standing up multiple public endpoints.

5Transform the payload

Automations are picky about input shape. Rather than adding a "normalize" step inside every n8n workflow, reshape the payload once in Relayers. Open Transformations, pick an engine (jq, jsonata, javascript, or go_template), and use the built-in test playground to iterate against a real sample.

A small jq transform that flattens a provider event into the flat object an n8n workflow expects:

{
  event: .type,
  customer_id: .data.object.customer,
  amount: (.data.object.amount / 100),
  received_at: now
}

Test it in the playground, attach it to the rule, and your local automation receives clean, predictable input every time.

Verify what arrived

Because these platforms don't sign their requests, authenticity is on you. Add a shared-secret header on the sending side (a custom header in Webhooks by Zapier, the Make HTTP module, or the n8n HTTP Request node), and check for it in your n8n workflow or handler. Relayers forwards headers untouched, so a header set by the sender arrives exactly as sent — use the payload inspector in the Events view to confirm both the body and your secret header made it through end to end.

Going to production

Once the workflow is solid locally, promotion is a one-line change: in Rules, switch the destination from the tunnel to a public URL — your production n8n Cloud webhook, a Make scenario URL, or a Zapier catch hook. Nothing else moves. The provider still points at the same stable Relayers endpoint; only the last hop changes from localhost to the cloud automation. Your JQ filters and transformations carry over unchanged.

Tip: use Export to save the endpoint, rules, and transformations as a JSON bundle, then Import it into another workspace to reproduce the same routing elsewhere.

Troubleshooting

• n8n test URL vs production URL. n8n exposes two webhook URLs per trigger: a test URL that's active only while the canvas is listening, and a production URL that's live when the workflow is active. If forwarded events vanish, you're likely pointing the tunnel at the test path while the editor isn't listening — activate the workflow and use the production path.
• Wrong content type. n8n and Make branch on Content-Type. If your JSON is being treated as raw text, confirm the sender sets Content-Type: application/json; Relayers passes it through as-is.
• Missing secret header. If your workflow rejects everything, inspect the delivered event in the payload inspector. If the shared-secret header isn't there, it was never set on the sending side — add it to the Zapier/Make/n8n outbound request, not to Relayers.
• Tunnel not receiving. Make sure relayers listen --forward localhost:5678 is still running and the rule's destination is set to the tunnel, not a public URL.

Wrap-up

Automation platforms are great at reacting to webhooks, but painful to develop against locally. Put Relayers in front as the stable ingress and router: one permanent public URL, JQ-based fan-out to different local ports, transformations to match each workflow's expected shape, and a tunnel that carries live events straight to your self-hosted n8n on localhost. Build offline against real traffic, then flip the destination to your cloud automation when you're ready — no re-plumbing required.

Start free at relayers.app and download the desktop app to create your first endpoint.