n8n Webhook Event Router: Jira, GitHub & Stripe to Slack in 2026

The n8n Webhook node is the most versatile trigger in the platform — it lets external services push real-time events directly into your workflows. While most tutorials focus on connecting a single service, production automation often demands a centralized event router: one webhook endpoint that accepts payloads from Jira, GitHub, and Stripe simultaneously, then routes each event to Slack based on its source. In this tutorial, you'll build that exact pattern in under 20 minutes using n8n's Webhook node, Switch node, and Slack node — all running on a managed instance from n8nautomation.cloud.

What Is an n8n Webhook Event Router and Why Build One?

A webhook event router is a single HTTP endpoint that receives payloads from multiple external services, inspects each payload to determine its origin, and forwards it to the appropriate destination. Instead of creating separate webhook URLs for Jira, GitHub, and Stripe — each with its own workflow — you build one central workflow that handles all incoming events.

This pattern solves three common problems:

• URL sprawl: Managing a dozen webhook URLs across services becomes a maintenance burden. One URL simplifies configuration on every service.
• Duplicate logic: If every service needs to log events, authenticate requests, or format timestamps the same way, that logic lives in one place instead of three.
• Cross-service visibility: A single workflow shows you all incoming events in one execution history, making debugging and monitoring straightforward.

n8n is ideal for this because its visual workflow builder lets you connect the Webhook node, Switch node, and Slack node without writing code. The entire pattern takes roughly 15 minutes to build.

Consider a real scenario: your engineering team uses Jira for tickets, GitHub for pull requests, and Stripe for payment events. Instead of maintaining three separate notification workflows, you set up one webhook endpoint in n8n. Every service posts to that single URL. The workflow inspects the payload, determines the source, and posts a formatted Slack message to your team's operations channel.

Setting Up Your Central Webhook Endpoint in n8n

The first step is creating a new workflow and adding a Webhook node as the trigger. This node will listen for incoming HTTP POST requests from any external service.

1. Create a new workflow in your n8n instance. Name it Event Router.
2. Add a Webhook node from the trigger nodes panel.
3. Configure the node:
   • HTTP Method: POST
   • Path: /events (or any path you prefer)
   • Response Mode: Last Node — this ensures n8n sends a response after the workflow completes
   • Response Data: JSON — add a simple {"status": "received"} body
4. Click Listen for Test Event to activate the endpoint. n8n will display a unique webhook URL that looks like https://yourname.n8nautomation.cloud/webhook/events.
5. Copy this URL — you'll configure each external service to POST to it.

Now configure each external service to send events to this URL:

• Jira: Go to Project Settings → Automation → Create rule. Choose a trigger (Issue Created, Issue Updated, etc.) and add a Send Webhook action. Paste your n8n webhook URL and select JSON as the format.
• GitHub: Go to your repository → Settings → Webhooks → Add webhook. Set the Payload URL to your n8n webhook URL. Choose application/json as the content type. Select individual events (Issues, Pull Requests, Pushes) or send everything and filter in n8n.
• Stripe: Go to the Stripe Dashboard → Developers → Webhooks → Add endpoint. Enter your n8n webhook URL. Select the events you want to receive — charge.succeeded, invoice.paid, and customer.subscription.updated are common choices.

Routing n8n Webhook Events by Source with the Switch Node

Once your webhook endpoint receives a payload, you need to determine which service sent it. The Switch node in n8n makes this straightforward. It inspects incoming data and routes the execution down the matching branch.

There are two reliable ways to identify the source of a webhook payload:

1. Route by HTTP header: Each service sets a distinct User-Agent header. Jira sends Atlassian Webhook, GitHub sends GitHub-Hookshot/..., and Stripe sends Stripe/1.0. You can access headers in n8n via {{ $node["Webhook"].json.headers }}.
   • Pro: Works with any payload structure
   • Con: Headers can be spoofed (not a concern inside a trusted network)
2. Route by body field: Each service includes unique fields in its JSON body. GitHub payloads contain a repository object. Jira payloads contain issue and project fields. Stripe payloads contain an object with a type field.
   • Pro: Works with webhook forwarding services that may strip headers
   • Con: Requires knowing the payload structure for each service

For this tutorial, use the body field approach since it's more portable. Add a Switch node after the Webhook node and configure it as follows:

1. Set Mode to Expression.
2. Use a single expression that checks all conditions: {{ $json.has("repository") ? "github" : $json.has("issue") ? "jira" : $json.object.type ? "stripe" : "unknown" }}
3. Create four output branches in the Switch node settings: github, jira, stripe, and unknown.
4. Click the expression output fields on each branch and enter github, jira, stripe, and unknown respectively.
5. Save the Switch node configuration.

The nested ternary expression checks each condition in sequence. If $json.has("repository") is true, the payload routes to the github branch. If not, it checks for issue, then for object.type. Any payload that doesn't match goes to unknown. This fallback ensures you never silently drop an event from a service you haven't configured yet.

Sending Notifications to Slack via the Slack Node

With your routing logic in place, it's time to send formatted notifications to Slack. Each branch of the Switch node needs a Slack node configured with a message template tailored to that service's data.

1. Add a Slack node to the github output of the Switch node.
2. Configure the Slack connection:
   • Credential: Select or create a Slack OAuth credential. You'll need a Slack app with the chat:write scope added to the channel you want to post in.
   • Resource: Message
   • Operation: Post
3. Set the Channel to #ops-alerts (or your team's operations channel).
4. In the Text field, build a message using n8n expressions:
   • For GitHub: *New GitHub Event* Repository: {{ $json.repository.full_name }} Action: {{ $json.action }} URL: {{ $json.pull_request.html_url || $json.issue.html_url }}
   • For Jira: *Jira Update* Issue: {{ $json.issue.key }} — {{ $json.issue.fields.summary }} Status: {{ $json.issue.fields.status.name }} Updated by: {{ $json.user.displayName }}
   • For Stripe: *Stripe Event* Type: {{ $json.object.type }} Amount: {{ $json.object.amount / 100 }} {{ $json.object.currency.toUpperCase() }} Customer: {{ $json.object.customer }}

Repeat this process for the jira and stripe branches — add a Slack node to each with its own message template. For the unknown fallback branch, add a Slack node that posts the raw JSON payload to a private debugging channel. This ensures you never miss an event from a new service you haven't configured yet.

Testing Your Event Router End-to-End

Before wiring up real services, test the router with simulated payloads. This confirms your Switch node routing is correct and all Slack messages render properly.

1. Open your webhook URL or use curl to send test payloads:
   • GitHub simulation: curl -X POST https://yourname.n8nautomation.cloud/webhook/events -H "Content-Type: application/json" -d '{"repository": {"full_name": "test/repo"}, "action": "opened", "pull_request": {"html_url": "https://github.com/test/repo/pull/1"}}'
   • Jira simulation: curl -X POST https://yourname.n8nautomation.cloud/webhook/events -H "Content-Type: application/json" -d '{"issue": {"key": "TEST-123", "fields": {"summary": "Test issue", "status": {"name": "In Progress"}}}, "user": {"displayName": "Alice"}}'
   • Stripe simulation: curl -X POST https://yourname.n8nautomation.cloud/webhook/events -H "Content-Type: application/json" -d '{"object": {"type": "charge.succeeded", "amount": 2000, "currency": "usd", "customer": "cus_test"}}'
2. Check that the workflow executed correctly:
   • n8n highlights each executed node in green.
   • Click each node to inspect the input and output data.
   • Verify the Switch node routed each payload to the correct branch.
3. Confirm each test sends the correct Slack message to your channel. Check that the formatting renders properly and all expression values are populated.
4. If you're hosting on n8nautomation.cloud, open the Logs tab in your dashboard to view detailed execution logs for each incoming webhook. You can inspect the raw request headers and body, the execution path through every node, and any error messages — this is invaluable when debugging why a specific payload didn't route as expected.
5. Once all three simulated events route correctly, configure each real service to send live events. Start with a single event type per service and verify the workflow processes it before enabling all event types.

Production Tips for Webhook Event Routers

Moving your event router from a test workflow to production requires a few hardening steps. Here are the most important ones to implement before relying on it for real traffic:

• Verify webhook signatures. GitHub signs its payloads with an HMAC-SHA256 hash using a shared secret. Stripe uses a similar signature scheme. Use n8n's Code node to compute the expected signature from the raw body and compare it against the incoming X-Hub-Signature-256 (GitHub) or Stripe-Signature (Stripe) header. Never trust an unsigned webhook in production.
• Add error handling per branch. Wrap each Slack node in an Error Trigger workflow or use n8n's built-in error handling. If the Slack API is rate-limiting your requests or the channel is removed, the rest of the router should still process incoming webhooks. Set each branch to Continue on Fail in the node error handling settings.
• Monitor execution latencies. Webhook deliveries should complete within seconds. If you notice delays, check whether the Slack API is throttling your requests. n8n's execution logs show the duration of each node — use them to identify bottlenecks. A single slow Slack node can hold up the entire router.
• Set up deduplication. Stripe and GitHub occasionally deliver the same event twice. Add an IF node with a check against a database (Redis, Postgres, or simply a JSON file in an n8n Code node) to skip events you've already processed. Key the deduplication on the event ID provided by each service — X-GitHub-Delivery for GitHub, id for Stripe, and webhookEvent.id for Jira.
• Log unknown events comprehensively. Your fallback branch should write unknown payloads to a Google Sheet, a database, or a Slack debugging channel. New services or API updates can introduce unexpected payload structures — logging them helps you catch changes before they cause silent failures.
• Use environment variables. Store your Slack channel names, webhook secrets, and destination URLs as n8n environment variables. This keeps your workflow portable between test and production instances and avoids hardcoding sensitive values in node configurations. On n8nautomation.cloud, you can set environment variables directly from the dashboard.
• Version control your workflow. Export your event router workflow as JSON and commit it to your Git repository. If something breaks during an update, you can restore the previous version in seconds. n8n's built-in git integration works well for this, or you can export manually from the workflow menu.

If you ever need to move this event router to a different n8n instance — whether for scaling, testing, or team separation — the migration tool provided by n8nautomation.cloud transfers your entire workflow (the Webhook trigger, Switch node, Slack nodes, and all routing logic) in seconds. You'll only need to reconnect your Slack credential and update the environment variables on the new instance. Credentials are never migrated for security reasons, so each destination always requires a fresh authentication setup.