Why a channel you can see still fails from the API
Slack's Web API distinguishes between a user being able to see a channel in the Slack UI and a bot token having API-level access to it. For private channels, and in some workspace configurations for public channels too, a bot must be explicitly invited (via /invite @yourbot in that channel) before API calls addressed to that channel ID succeed — being an admin or having the app installed workspace-wide is not the same as channel membership.
Community reports of this error specifically describe it occurring when sending to multiple users or to a channel that was not the one the bot was added to, which points to a membership gap rather than a broken credential.
Diagnose which of the four causes applies
- Private channel, bot never invited: the single most common cause. Open the channel in Slack and run /invite @your-bot-name; if the bot was not already a member, this alone resolves it.
- Channel selected by name in n8n but resolved against a stale list: n8n's channel picker caches the list it fetched at credential-setup time; if a channel was renamed or recreated, the stored ID can point at a channel that no longer exists under that name.
- Bot token from a different workspace: if the same n8n instance has multiple Slack credentials for different workspaces, using the wrong credential on a node sends a workspace-A channel ID against a workspace-B token, which Slack reports as channel_not_found rather than a permissions error.
- Legacy user-token credential instead of bot-token credential: an older Slack credential created against a user OAuth token (rather than a bot token) resolves channel visibility according to that individual user's own channel membership, not the app's bot membership — so a channel the human user can see but the app was never added to fails the same way.
Verify bot membership directly with the API before guessing
Rather than assuming, you can confirm exactly what Slack's API sees by calling conversations.info with the channel ID and the same bot token n8n's credential uses. The response's `is_member` field tells you definitively whether the bot is currently a member of that specific channel — this removes guesswork about whether an earlier /invite actually took effect.
curl -H "Authorization: Bearer xoxb-your-bot-token" \
"https://slack.com/api/conversations.info?channel=C0123456789"
# Look for: "is_member": true (bot has access)
# or: "is_member": false (bot not in channel — invite it)
# or an "error" field like "channel_not_found" (confirms it's an ID/token mismatch, not a membership gap)
Fix each cause directly
For the membership cause, invite the bot to the specific channel using /invite in Slack itself — this cannot be done from n8n's side, since it is a Slack-side membership action, and it takes effect immediately without needing to reconnect the credential.
For the stale-ID cause, open the node's channel parameter and re-select the channel from the dropdown (which re-fetches the current list) instead of relying on a previously typed or pasted channel ID, then save the workflow again.
For the wrong-workspace cause, open the node's credential dropdown and confirm the connected workspace name shown matches the workspace where the target channel actually lives — if you manage multiple Slack workspaces from one n8n instance, name credentials explicitly by workspace to avoid picking the wrong one.
For the legacy-token cause, recreate the Slack credential in n8n using the bot token (xoxb-) generated from the app's OAuth & Permissions page under Bot User OAuth Token, rather than a personal/user token — the two tokens see different channel lists even in the same workspace.
Verify the fix
- Confirm the bot appears in the channel's member list inside Slack after inviting it, or confirm `is_member: true` via the conversations.info check above.
- Re-select the channel from the node's dropdown rather than trusting a previously saved ID, and execute once manually to confirm success before reactivating any scheduled or triggered version.
- If multiple Slack credentials exist on the instance, rename each one to include the workspace name so future node configuration cannot silently cross workspaces.
- Confirm the credential's token prefix is xoxb- (bot token) rather than xoxp- (user token) if you inherited an older Slack integration.
Sources checked for this guide
The distinct failure modes below come from separate n8n Community threads and a GitHub issue describing channel-resolution problems in the Slack Trigger node; the API verification method comes from Slack's own conversations.info documentation.
Frequently asked questions
I can see the channel in Slack, why does the bot say it doesn't exist?
Being visible to you as a human user is not the same as the bot having API access. Private channels specifically require the bot to be invited with /invite @yourbot before API calls addressed to that channel will succeed.
Does re-authenticating the Slack credential fix channel_not_found?
Usually not, since the token itself is typically valid — the issue is channel membership or a stale/wrong channel ID, not the credential's validity. Re-authenticating does not add the bot to a channel.
How do I check bot membership without guessing?
Call Slack's conversations.info API endpoint directly with the channel ID and the bot token, and read the is_member field in the response — this tells you definitively rather than relying on what the Slack UI shows a human user.
How do I avoid this when managing multiple Slack workspaces in one n8n instance?
Name each Slack credential explicitly by workspace, and always re-select the channel from the node's dropdown (not a pasted ID) after confirming the correct credential is selected, so the ID and token are guaranteed to match the same workspace.
