Discord API Tester

Before you paste a live bot token

Discord's API is versioned and changes over time; endpoints, permissions and error shapes are all subject to change. This page is an independent guide, not documentation. Check the official Discord developer documentation for authoritative details.

The Bot scheme: Discord's most common gotcha

If you take one thing from this page, take this. Discord does not accept bot tokens as bearer tokens. The header your bot must send is the word Bot, a space, then the token:

Authorization: Bot YOUR_BOT_TOKEN

Send Authorization: Bearer YOUR_BOT_TOKEN instead and Discord rejects it with a 401, even though the token is perfectly valid. This is why the tester above prefills the header directly in the Headers tab and why the Auth tab's Bearer option is the wrong choice here — replace the placeholder with your real token and the request is correctly formed. Bearer is not useless in Discord's world; it is the scheme for OAuth2 access tokens obtained through Discord's authorization flow on behalf of a user, which is a different credential entirely.

Endpoints live under https://discord.com/api/ followed by a version segment such as v10. Pinning the version explicitly, as the prefilled URL does, is the right habit: it means a future default change cannot alter your request's behaviour without you choosing it. Because the scheme keyword is easy to get subtly wrong, Copy as cURL in the Body tab is worth using — it prints the exact header text, where a missing space or a capitalisation slip is obvious. The HTTP headers guide covers the general rules for authorization headers.

What a valid response looks like

The fastest check is /users/@me, prefilled above. With a valid bot token it returns HTTP 200 and a JSON object describing the bot user — its id, username and a bot flag set to true. That confirms three things at once: the token is live, the header scheme is right, and your request reached Discord.

For a request that needs no credential at all, the gateway endpoint returns a JSON object containing a WebSocket URL. It is a useful control: if the gateway call succeeds but /users/@me returns 401, connectivity is fine and the problem is definitively your credential rather than anything else. That kind of isolation — change one variable, keep the rest fixed — is most of what effective API debugging consists of.

When Discord rejects something it returns a JSON body carrying a human-readable message field and a numeric code that identifies the specific error more precisely than the HTTP status can. Read both. The status tells you the category; the code tells you which member of that category you hit.

Testing Discord webhooks

Discord webhooks are the friendlier half of this page, because they need no token. A webhook URL is itself the credential: it contains an id and a secret token in the path, and anyone holding the URL can post to the channel it is bound to. Treat a webhook URL as seriously as a password — it is one.

To test one, switch the method to POST, paste the full webhook URL, open the Body tab and send a JSON object with a content field holding your message text. Set Content-Type: application/json in the Headers tab, since you are sending a JSON body. If it works you will get HTTP 204 No Content back — success, with an intentionally empty body — and the message will appear in the channel. A 204 with nothing in the response pane is not a failure, and this surprises people every time.

Note that a webhook URL is the credential, so it would otherwise be written straight into the request history in your browser's local storage. The token segment is redacted before saving — the stored entry keeps the webhook id but replaces the token with *** — so reusing it from history means pasting the full URL again. This is the inverse of the usual advice about inbound webhooks, which is covered on the webhook tester page — that page is for payloads arriving at an endpoint you host.

Creating a bot token

Bot tokens come from an application in Discord's developer portal. Create an application, add a bot user to it, and the bot section will let you reveal or regenerate the token. Discord shows the token once at creation; if you miss it, regenerate rather than hunting for it.

A token alone does not grant access to any server. The bot must be invited, and the permissions you select at invite time determine what it may actually do once inside. This is why a token can be completely valid while a specific call still fails — the bot is authenticated but not authorised in that particular guild or channel. Some capabilities also depend on privileged intents that must be enabled explicitly in the application settings.

Reading 401, 403 and 429 from Discord

A 401 Unauthorized means the credential is missing, malformed or rejected. With Discord, check the scheme keyword before anything else: Bot rather than Bearer, one space, no stray whitespace pasted along with the token. After that, consider whether the token was regenerated somewhere else, which silently invalidates every copy of the old one.

A 403 Forbidden is a different animal: Discord knows exactly who your bot is and is refusing anyway. This almost always means permissions — the bot lacks the required permission in that channel or guild, or is not a member of it, or a required privileged intent was never enabled. A 401 says "I don't know you"; a 403 says "I know you, and no".

A 429 Too Many Requests is where Discord is more informative than most APIs. It returns a JSON body containing a retry_after value telling you how long to wait, alongside rate-limit headers, and it distinguishes per-route limits from a global limit that applies to your bot as a whole. Discord's limits are applied per route bucket rather than as a single global number, so this page quotes no figures — read the retry_after Discord actually sends and honour it. Hammering through a 429 is the reliable way to earn a much longer restriction.

For OAuth2 flows that hand you a token you cannot identify, the JWT decoder will tell you locally whether it is a JSON Web Token with readable claims or an opaque provider string. For endpoints with no Discord-specific defaults, use the REST API tester.

Test another provider's API

Frequently asked questions