Slack API in n8n: HTTP 200 With "ok": false (not_authed, invalid_auth, unknown_method)

If a Slack call in n8n looks successful but nothing happens in Slack, check the response body. In my tests the Slack Web API answered HTTP 200 even when the request failed, and put the failure in the JSON as "ok": false with an error code such as not_authed or invalid_auth. A node or workflow that only treats non-2xx status codes as failures will not notice.

What I tested

On 2026-10-27 I sent POST requests to https://slack.com/api/ with curl, using made-up tokens only. No real workspace was involved and no message was sent.

• Every failure I produced came back as HTTP 200. The failure was only visible in the JSON.
• not_authed and invalid_auth mean different things in these tests. not_authed appeared when no token was recognized, including when I sent a token without the Bearer word. invalid_auth appeared when a token arrived in a recognized form and was not accepted.
• The token check came before the body check. With a made-up token and a body that was not JSON, I still got invalid_auth and not a JSON error.
• The missing_charset warning appeared when I sent a JSON content type without charset=utf-8. The same request with the charset (the chat.postMessage test) had no warning.

The Slack Web API documentation says every response contains a top-level boolean ok, and that on failure ok is false and error holds a short machine-readable code. It prefers the token in the Authorization header (Bearer followed by the token), allows a token parameter in the POST body, and says a token cannot be sent as a query parameter. The page I read does not say which HTTP status accompanies an error, so the 200 above is what I observed.

What this means in n8n

If your workflow only reacts to failed HTTP statuses, a Slack error can pass through as a success and the next nodes run with an error body. A simple guard is to check the ok field in the response before continuing, for example with an If node that tests whether {{ $json.ok }} is true. I use the same idea of a branch that only runs on the good path in my Telegram approval workflow. I did not run this exact If node on a Slack response in n8n, so treat it as a suggestion to try.

A short checklist

1. Look at the response body, not only the status. If it contains "ok":false, read the error value.
2. not_authed: no token reached Slack in a form it recognized. Check the credential and that the header value is Bearer followed by a space and the token.
3. invalid_auth: a token arrived but was not accepted. Check that it is the right token for the right workspace, and replace it if it was revoked or mistyped. I only tested made-up tokens, so these are possible causes, not results.
4. unknown_method: check the method name in the URL for typos.
5. Send JSON requests with Content-Type: application/json; charset=utf-8 to avoid the charset warning.

A quick test with a real token looks like this. I did not run it with a real token, so I cannot show the successful response.

curl -X POST \
-H "Authorization: Bearer YOUR_TOKEN" \
https://slack.com/api/auth.test

This is about the Web API. Posting through an incoming webhook URL gives different errors, which I covered in this Korean article on Discord and Slack webhook errors. The same idea of separating "no key" from "wrong key" also applies to the GitHub API.

What I did not test

• I did not use a real token, so I did not see missing_scope, channel_not_found, token_revoked or a successful response.
• I did not test rate limits. The response headers list retry-after as exposed, but I never triggered a 429.
• I did not run any of this inside n8n, so I did not check how its nodes treat these responses by default.
• I tested a few methods on one day.

Source: Slack documentation, Web API. The responses above come from my own requests on 2026-10-27.