Fix n8n Slack Trigger 401: Add the Signing Secret for n8n 3.0

Introduction

You upgraded toward n8n 3.0, or you opened the Migration Report on your 2.x instance, and your Slack trigger stopped being trustworthy. Events that used to fire now fail, or the workflow cannot be published at all, and the cause is not your workflow logic. It is a missing credential value: the Slack app signing secret. This tutorial fixes the n8n Slack Trigger 401 by finding the correct secret, putting it in the right n8n credential, and re-verifying the Slack webhook, so real Slack events run again and forged requests do not.

Quick answer

Copy the Signing Secret from your Slack app under Basic Information, paste it into the signing secret field of the matching n8n Slack credential, save, re-publish the workflow, and re-verify the Slack Event Subscriptions Request URL.

Evidence

n8n 3.0 is a security cleanup release, and the Slack change is stated plainly in the official announcement. The n8n 3.0 announcement says: “Slack credentials require a signing secret, so nobody can send forged requests pretending to be Slack.” That sentence is the whole diagnosis. Before 3.0, a Slack credential could work without a signing secret, which meant the trigger could accept requests without proving they came from Slack. In 3.0, that gap is closed, so a credential without the secret is incomplete, not merely less secure.

Timing matters for planning. The same announcement, published October 27, 2026, says n8n 3.0.0 beta is available that day and the stable release follows in early December. As of October 31, 2026, that means the smart move is to fix Slack credentials on 2.x now, while you still control the upgrade window, rather than discovering the failure during a production upgrade in December. Open Settings, then Migration Report, on your 2.x instance before upgrading, and treat every Slack trigger workflow it lists as a credential to fix.

The scale of the audience makes this a common failure, not an edge case. The n8n repository recorded 209,181 stars and 61,337 forks on GitHub as of October 31, 2026, which reflects a very large self-hosting base that will hit the same credential change in the same upgrade wave. A single missing field, repeated across many instances, is exactly the kind of upgrade breakage that looks like a Slack outage on the first morning and turns out to be a checklist item.

The mechanism behind the fix is documented by Slack itself. Slack signs every request it sends to your app, and Slack’s request verification documentation explains that Slack adds an X-Slack-Signature header to each request, created by hashing the request body with SHA-256 combined with an HMAC signing secret. The signed string follows the pattern v0, then the request timestamp, then the raw request body, joined by colons. n8n can only reproduce that signature if it holds the same secret, which is why pasting the client secret, a bot token, or an old verification token into the field never works. Only the signing secret reproduces the signature Slack computed.

Prerequisites

• An n8n instance on 2.x that you plan to upgrade, a 3.0 beta instance, or a 3.0 instance where the Slack trigger already fails.
• Admin access to the Slack workspace, or at least permission to view the Slack app settings for the app your workflow uses.
• The Slack app already created for this workflow, with OAuth installed in the workspace. If no app exists yet, create one first and install it before following this guide.
• A Slack channel where you can invite the bot and post a test mention.
• Permission to edit credentials and publish workflows in n8n, plus a few minutes of downtime tolerance for the trigger while you re-verify it.

Step-by-step guide

Step 1: List every Slack trigger workflow before you touch anything

Do not fix one workflow and assume the rest are fine. On a 2.x instance, open Settings, then Migration Report, and note every workflow that uses a Slack Trigger node. On a 3.0 instance where the failure already happened, open each Slack workflow and check which credential its trigger node uses, because several workflows often share one credential. Fixing that shared credential once fixes all of them, while fixing a single workflow leaves the others broken. Write down the credential name for each trigger, so you can confirm later that no trigger still points at an old, secret-free credential.

Step 2: Copy the signing secret from the Slack app

Open your Slack app settings and go to Basic Information, then scroll to the App Credentials section. Find Signing Secret and click Show to reveal it, then copy the value exactly. Do not copy the Client ID, the Client Secret, or the Bot User OAuth Token from nearby fields. Those values look similar and live on the same page, but none of them reproduces the request signature Slack computes. Paste the secret into a password manager or a secure note for the next step, and do not post it in a Slack channel, a ticket, or a screenshot. Anyone who holds the signing secret can forge requests that look like Slack, which defeats the protection you are adding.

Step 3: Paste the secret into the n8n Slack credential

In n8n, open Credentials, find the Slack credential your trigger uses, and paste the signing secret into its signing secret field. Save the credential. If the credential editor asks you to reconnect or re-authorize after the change, complete that step, because a saved value that was never applied to the active credential is a common reason the fix appears to fail. After saving, open the Slack Trigger node and confirm it still selects the same credential name you just updated. If the node points at a different credential, perhaps a duplicate created during an earlier troubleshooting attempt, update the node to use the corrected credential before proceeding.

Step 4: Re-publish the workflow and re-verify the Slack webhook

Set the workflow to Active, which is the state that makes the production webhook URL live. In your Slack app, go to Event Subscriptions, confirm Events are enabled, and check that the Request URL field holds the production webhook URL from the n8n trigger, not the test URL. The test URL only works while you are actively listening in the n8n editor, while the production URL only works when the workflow is Active, so mixing them up produces a verified URL in testing and silence in production. Slack attempts to verify the Request URL when you save it. Wait for Slack to show the URL as verified before moving on, because an unverified URL means Slack will not deliver events at all, no matter how correct the credential is.

Step 5: Test with a real Slack event, not a manual run

Invite the bot to a test channel if it is not already a member, then post a message that mentions the bot, for example by typing the bot name followed by a short test phrase. Open the workflow executions in n8n and confirm a new execution appears for that mention, with the event payload attached. A manual run from the editor does not prove the webhook works, because a manual run bypasses Slack signature verification entirely. Only a real event from Slack, arriving through the production URL and passing signature verification, proves the fix. If the execution appears, the credential, the webhook URL, and the event subscription are all correct at the same time.

Troubleshooting

The Request URL verifies, but mentions never start a workflow

This usually means the bot is not in the channel, or the event subscription does not include the event you are testing. Invite the bot to the test channel, then check Subscribe to bot events in Event Subscriptions and confirm the event you need, such as app_mention, is listed. If you changed scopes or event subscriptions after installing the app, reinstall the app in the workspace, because Slack only applies some permission changes after a reinstall. After reinstalling, re-check the Request URL verification, since a reinstall can reset subscription state.

You pasted a value, but verification still fails

You almost certainly pasted the wrong value from the App Credentials page. The Client Secret authenticates OAuth, the Bot User OAuth Token starts with xoxb and authorizes API calls, and the deprecated verification token is an older mechanism Slack replaced with signed secrets. None of those reproduces the X-Slack-Signature header. Go back to Basic Information, copy Signing Secret specifically, paste it into the n8n credential again, save, and re-publish. Check for a trailing space or a line break copied from the page, because a single extra character changes the HMAC output and fails every request.

The test URL works, but production stays silent

Slack allows only one Request URL per app, so you cannot register the test URL and the production URL at the same time. If Event Subscriptions still holds the test URL, production events have nowhere to go, even though editor test runs looked perfect. Replace the Request URL with the production URL from the trigger node, confirm the workflow is Active, and let Slack verify the production URL. Then test again with a real mention. Keep a note of which URL is registered, so the next person who opens the editor does not swap it back to the test URL during debugging.

The fix worked, then broke again after a secret rotation or app change

Rotating the signing secret, recreating the Slack app, or reinstalling it with new credentials invalidates the value stored in n8n. The symptom is a sudden return of 401 rejections on a workflow that worked yesterday, with no workflow change to explain it. Update the n8n credential with the current signing secret immediately after any rotation, re-publish the workflow, and re-verify the Request URL. If you recreated the app instead of rotating the secret, also redo the OAuth redirect URL and event subscriptions, because a new app has new credentials and new subscription state.

Self-hosted n8n verifies nothing, even with the correct secret

Slack must reach your webhook over public HTTPS. A self-hosted instance on localhost, behind a firewall, or behind a reverse proxy that blocks the webhook path will fail verification before signature checking even matters. Confirm the production webhook URL is reachable from the public internet, that TLS is valid, and that any reverse proxy forwards the webhook path to n8n without stripping headers. Our guide to fixing n8n webhook not registered errors behind a reverse proxy covers the proxy side of this failure, and our n8n Telegram trigger diagnostic checklist shows the same test-first pattern for another chat trigger.

FAQ

See the FAQ entries in the front matter above for the questions readers ask most: message-only nodes, disabling verification, reusing the same app, secret rotation, Cloud versus self-hosted differences, and why the failure appears as a 401.

Conclusion

The n8n Slack Trigger 401 in the 3.0 upgrade is a credential completeness problem, not a workflow bug. Copy the signing secret from the Slack app, paste it into the matching n8n credential, re-publish the workflow, and prove the fix with a real Slack mention through the production URL. Do that checklist for every Slack trigger workflow before the stable 3.0 release in early December, and the upgrade will not interrupt your Slack automations. Next, work through the full n8n 3.0 upgrade checklist and the complete n8n guide to catch the other breaking changes in the same release while you still have a calm upgrade window.

Frequently asked questions