Integrations

n8n Webhook Guide

n8n webhooks start a workflow when an HTTP request reaches a Webhook node. They are useful for automation flows that react to payments, form submissions, support events, repository activity, internal service alerts, or custom application events.

FastHook fits in front of n8n when the provider-facing URL needs request history, routing, retries, replay, source authentication, and safer recovery than a direct provider-to-n8n webhook URL. The provider sends events to a FastHook source, then FastHook delivers accepted events to the n8n production webhook URL as a destination.

n8n webhook model

  1. Add a Webhook node as the workflow trigger in n8n.
  2. Use the n8n Test URL while building and listening for one test event.
  3. Switch to the n8n Production URL after the workflow is saved and published.
  4. Use the FastHook Source URL as the provider-facing webhook URL.
  5. Create an HTTP destination that points to the n8n Production URL.
  6. Route events through a FastHook connection so retries, replay, and debugging stay visible.

Test URL vs production URL

n8n separates short-lived test webhooks from production webhooks. That is helpful while building, but it can confuse provider setup if the provider dashboard points to a test URL that stops listening. Keep the provider configured with the FastHook Source URL and change the downstream n8n destination only when the workflow is ready.

n8n URL typeUse it forOperational note
Test URLManual workflow development and one-off payload inspection.Requires listening for a test event and should not be registered as the provider production URL.
Production URLPublished workflows that should run automatically when events arrive.Use this as the FastHook HTTP destination target after the workflow is ready.
FastHook Source URLThe stable provider-facing webhook URL.Keeps request capture, source auth, retries, replay, and routing outside the n8n workflow.

Create a FastHook source

Use the generated FastHook source URL in Stripe, GitHub, a form tool, an internal service, or any other event producer. Add source authentication when the producer supports a shared secret, HMAC signature, or provider-specific signature.

Create source
curl -X POST "https://api.fasthook.io/v1/sources" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_3b5335b627084a838b" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Provider events for n8n",
    "description": "Provider-facing webhook source routed to n8n",
    "type": "WEBHOOK",
    "status": "enabled",
    "config": {
      "auth_type": null,
      "auth": null,
      "allowed_http_methods": ["POST"],
      "custom_response": {
        "content_type": "json",
        "body": "{\"ok\":true}"
      }
    }
  }'

Create the n8n destination

Point the HTTP destination at the n8n Production URL from the Webhook node. If the n8n workflow expects a header secret, configure the same custom header on the destination and in n8n's webhook authentication.

Create n8n destination
curl -X POST "https://api.fasthook.io/v1/destinations" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_3b5335b627084a838b" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "n8n production workflow",
    "type": "HTTP",
    "config": {
      "url": "https://n8n.example.com/webhook/provider-events",
      "http_method": "POST",
      "path_forwarding_disabled": true,
      "auth_type": "CUSTOM_HEADER",
      "auth": {
        "header_name": "x-fasthook-route-secret",
        "value": "receiver-secret"
      }
    }
  }'

Route provider events to n8n

Start with one explicit route, then add filters for event types, providers, environments, tenants, or workflow ownership. This keeps n8n workflows smaller and makes it easier to replay only the event family that failed.

Create connection
curl -X POST "https://api.fasthook.io/v1/connections" \
  -H "Authorization: Bearer fhp_xxx" \
  -H "x-team-id: tm_3b5335b627084a838b" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "provider-to-n8n",
    "source_id": "src_q6z62b6py5o79b",
    "destination_id": "des_TU9ioCk5EHUU",
    "rules": [
      {
        "type": "filter",
        "headers": {
          "x-event-type": { "$in": ["invoice.paid", "order.created", "lead.created"] }
        }
      },
      {
        "type": "retry",
        "strategy": "exponential",
        "interval": 30000,
        "count": 5,
        "response_status_codes": ["429", "500-599"]
      }
    ]
  }'

Debug n8n webhook failures

  • If n8n does not run, first check whether FastHook accepted or rejected the inbound provider request.
  • If FastHook accepted the request, inspect the routed event and destination attempt response body.
  • If n8n returns 404 or does not trigger, confirm the destination URL is the Production URL and the workflow is published.
  • If n8n returns 401 or 403, compare the destination custom header with the Webhook node authentication settings.
  • If the workflow timed out or failed after accepting the event, fix the workflow and replay the failed FastHook event instead of asking the provider to resend a whole batch.

When FastHook helps n8n most

  • Several providers need to route into different n8n workflows.
  • One provider event should fan out to n8n, Slack, Google Sheets, and an internal API.
  • The team needs searchable request history before events reach n8n.
  • Production recovery needs scoped retry or replay after an n8n workflow is fixed.
  • A provider cannot easily switch between staging, localhost, test URLs, and production URLs.

Related guides