コンテンツにスキップ

Apps & Bots overview

このコンテンツはまだ日本語訳がありません。

Status Stable · Last verified 2026-07-11 · API v10 · Sources Getting started, Application resource

“App” and “bot” are often used interchangeably, but they are different things.

  • An application is the top-level entity you register in the Developer Portal. It owns your Application ID, Public Key, OAuth2 credentials, command definitions, installation settings, and (optionally) a bot user.
  • A bot is an automated user account attached to an application. It has a bot token and appears in servers as a member. Not every app needs a bot: an app that only handles interactions over HTTP or does OAuth2 may have no gateway bot at all.

Think: the app is the project; the bot is one optional capability of it.

Item Secret? Portal location Used for
Application ID (a snowflake) No General Information Command registration, OAuth2 URLs, install links
Public Key No General Information Verifying inbound interaction signatures (Ed25519)
Bot token Yes Bot → Reset Token Authenticating as the bot (Authorization: Bot <token>)
Client ID No OAuth2 (same value as Application ID) OAuth2 flows
Client secret Yes OAuth2 → Reset Secret OAuth2 token exchange

Rotate any leaked bot token or client secret immediately — see Security.

REST requests use the bot token in the Authorization header with the Bot scheme:

Terminal window
curl "https://discord.com/api/v10/users/@me" \
-H "Authorization: Bot $DISCORD_BOT_TOKEN"

Gateway connections authenticate with the same token in the IDENTIFY payload. The token encodes the application ID (first segment, base64) — but never rely on parsing it; treat it as opaque and secret.

A bot’s actual power in a server is the intersection of:

  1. OAuth2 scopes granted at install (e.g. bot, applications.commands), and
  2. Guild permissions — the permission bitfield of the bot’s role(s) plus channel overwrites.

Neither is “Administrator by default.” Compute the minimal permission bitfield your features need and request only that.