Slack API Tester

Before you paste a live Slack token

Slack changes its API over time — methods, scopes and error strings are all subject to change. This page is an independent guide, not documentation. Check the official Slack Web API documentation for authoritative details.

How the Slack Web API is shaped

The Slack Web API does not look like a typical REST API, and that trips people up on their first call. Instead of nouns and HTTP verbs — GET /channels/123 — Slack exposes methods. Every call goes to https://slack.com/api/ followed by a dotted method name: auth.test, conversations.list, chat.postMessage, users.info. The method name carries the meaning; the URL path is not a resource identifier.

Arguments can be supplied as query-string parameters or, for methods that accept it, as a JSON request body. Read-oriented methods are comfortable with a plain GET and query parameters, which is why the Params tab above is a natural home for things like a channel ID or a pagination cursor. Methods that write — posting a message, for example — are normally sent as POST. When you send JSON to Slack, set the content type to application/json; charset=utf-8; Slack is explicit about wanting the charset, and it is a cheap habit to adopt.

Authentication is a plain bearer token: the header is Authorization: Bearer xoxb-your-token. Choose Bearer token in the Auth tab and the tester builds that header for you. If you want to see exactly what is being sent, open the Body tab and press Copy as cURL — the generated command shows the full header set, which is often the fastest way to settle an argument about whether a header is actually present. The HTTP headers reference covers the general rules if you want the background.

Reading a Slack response: ok is the real status

Here is the single most useful thing to know about testing Slack. An HTTP 200 from Slack does not mean your call worked. The Web API reports application-level outcomes inside the JSON body through an ok boolean. A successful call returns "ok": true plus whatever payload the method produces. A failed call very often returns HTTP 200 as well — with "ok": false and an error string explaining what went wrong.

A valid auth.test call comes back with ok: true and identity fields describing the workspace and the identity behind the token. That is the quickest possible confirmation that a token is alive and which workspace it points at. An invalid one comes back with ok: false and an error such as invalid_auth, meaning the token is not accepted, or not_authed, meaning no token reached Slack at all — usually because the Auth tab was left on "No authentication" or the token field was empty.

The other error you will meet constantly is missing_scope. This one is good news in disguise: the token authenticated fine, so your credentials are correct, but the Slack app was never granted the OAuth scope this particular method requires. The fix is always the same shape — add the scope to the app, reinstall it into the workspace so that a fresh token is minted, then retry with the new token. Re-using the old token after adding a scope is a classic wasted afternoon, since scopes are baked into the token at install time.

Because the interesting part of a Slack response is nested JSON, the syntax highlighting above does real work. If you want to pull a response apart further, paste it into the JSON formatter.

Creating a token to test with

Tokens come from a Slack app, not from your account settings. In broad strokes: create an app at Slack's developer site, open its OAuth and permissions configuration, add the scopes the methods you care about require, then install the app into a workspace. Installation is what produces the token — a bot token beginning xoxb- that represents the app itself, and optionally a user token beginning xoxp- that acts on behalf of the installing user.

For testing, install into a workspace you do not mind experimenting in. A scratch workspace costs nothing to create and turns "what happens if I post to the wrong channel" from an incident into a shrug. Grant the narrowest scope set that lets your call succeed; if you find yourself adding scopes one at a time in response to missing_scope errors, that is the process working correctly.

When Slack pushes back: 401, 403 and 429

Even though Slack prefers the ok envelope, real HTTP status codes still appear, and they mean roughly what they mean everywhere else.

A 401 Unauthorized is about identity: the credential is missing, malformed or rejected. In Slack's world you are more likely to see this expressed as ok: false with invalid_auth, but the diagnosis is identical — check that the Authorization header is present, that the scheme is Bearer, and that you have not pasted a token with a stray space or newline attached. Copy-paste whitespace is a genuinely common cause and is invisible in most editors.

A 403 Forbidden is about permission rather than identity: Slack knows who you are and is declining anyway. Scope problems are the usual root cause, as are workspace or enterprise policies that restrict what apps may do.

A 429 Too Many Requests means you are calling faster than the method's rate tier allows. Slack applies rate limits per method and per workspace, and different methods sit in different tiers — a bulk listing method is treated far more conservatively than a trivial one. When you are limited, Slack sends a Retry-After header telling you how many seconds to wait. Respect it rather than retrying immediately; tight retry loops are the fastest route to a longer cool-down. Because rate tiers change, this page deliberately quotes no specific numbers — read the value Slack actually sends back, which the response header panel above will show you.

Beyond the Web API

Not everything Slack does is a Web API method. Incoming webhooks give you a URL that accepts a JSON payload and posts it into a channel, with the destination baked into the URL rather than chosen per request. Slack also calls you: slash commands, interactive components and the Events API all deliver HTTP requests to an endpoint you host. Debugging that inbound direction is a different job, and the webhook tester is the page for it.

If you are working with Slack's OAuth flow and end up holding a token-shaped string you cannot identify, the JWT decoder will tell you whether it is a JSON Web Token with a readable payload or an opaque provider-issued string like Slack's own tokens. For everything else — your own service, a partner API, a staging environment — the general REST API tester is the same console without Slack-specific defaults.

Test another provider's API

Frequently asked questions