Discord Bot Invite Link: OAuth2 URL, Scopes, Permissions and Install Contexts

A Discord bot invite link is an OAuth2 authorize URL: https://discord.com/oauth2/authorize?client_id=YOUR_APP_ID&scope=bot+applications.commands&permissions=PERMISSION_INTEGER. Generate it in the Developer Portal under OAuth2 > URL Generator, or set a default Install Link on the Installation page. The person who opens it must have the Manage Server permission in the server they pick.

Last verified: November 2026 against Discord's OAuth2, Application and Permissions documentation and the developer change log.

https://discord.com/oauth2/authorize?client_id=123456789012345678&scope=bot+applications.commands&permissions=84992

That link adds the bot user with View Channels, Send Messages, Embed Links and Read Message History (84992), and lets the app register slash commands. Paste any invite link into the Discord permissions calculator to see exactly which permissions a given integer grants, or to build one from checkboxes.

Discord's OAuth2 documentation calls this the bot authorization flow - a "server-less and callback-less" OAuth2 flow. Unlike a normal OAuth2 login, it needs no redirect_uri and no response_type, because your app does not receive a user access token.

https://discord.com/oauth2/authorize
  ?client_id=123456789012345678          # Application ID from General Information
  &scope=bot+applications.commands      # space-separated, URL-encoded as + or %20
  &permissions=84992                    # bitfield of bot permissions, as a decimal string
  &guild_id=987654321098765432          # optional: preselect a server
  &disable_guild_select=true            # optional: lock that selection
  &integration_type=0                   # optional: 0 = server install, 1 = user install

(The comments are for reading only; a real URL is one line.)

One behavior worth knowing: if you pass only client_id (optionally with permissions, guild_id or disable_guild_select), Discord uses the Default Install Settings from the portal. Adding scope, integration_type or redirect_uri overrides them. That is why a link that "used to ask for permissions" can change after someone edits the Installation page.

If you request any scope beyond bot and applications.commands (for example identify), the flow becomes a full authorization code grant: response_type=code is mandatory and Discord redirects to your registered redirect URI.

Option 1: OAuth2 URL Generator

1. Open your app in the Developer Portal and go to OAuth2 > URL Generator.
2. Tick bot and applications.commands under scopes. A Bot Permissions panel appears once bot is ticked.
3. Tick the permissions the bot needs. The integer updates as you go.
4. Copy the generated URL at the bottom.

Good for one-off links and for links with a specific permission set per audience.

Option 2: Install Link (Installation page)

Discord's getting started guide now leads with this. On the Installation page:

1. Under Installation Contexts, choose Guild Install, User Install, or both. Discord's Application docs note that newly created apps support only guild installation by default.
2. Under Install Link, select Discord Provided Link (the alternatives are Custom URL and None).
3. In Default Install Settings, add applications.commands for User Install, and applications.commands plus bot with your chosen permissions for Guild Install.
4. Copy the link. It is just https://discord.com/oauth2/authorize?client_id=...; the scopes and permissions come from the settings.

With an install link configured, an Add App button appears on your app's profile and App Directory page. Selecting None removes that button and makes the app ineligible for the App Directory. Discord Provided Links are limited to the bot and applications.commands scopes; use a Custom URL if you need something else.

Hand-assembling the query string is where typos creep in: a space instead of + in the scope, a permissions value copied with a thousands separator, a client secret pasted as the client ID. Build it with a URL library instead:

from urllib.parse import urlencode

params = {
    "client_id": "123456789012345678",
    "scope": "bot applications.commands",   # urlencode turns the space into +
    "permissions": str(1024 | 2048 | 16384 | 65536),   # 84992
}
print("https://discord.com/oauth2/authorize?" + urlencode(params))

A few habits that keep invite links maintainable once other people depend on them:

• Put your own redirect in front of it. Publish yourdomain.com/invite and redirect it to the Discord URL. When you change permissions or switch to a different app, every old link in READMEs, listing sites and support macros keeps working.
• Use separate links per audience. A "minimal" link for cautious server owners and a "full features" link with moderation permissions, both pointing at the same app, lets admins choose what they grant.
• Preselect the server in support flows. When you already know the guild (for example, a customer is setting up from your dashboard), pass guild_id plus disable_guild_select=true so they cannot add the bot to the wrong server.
• Document the integer. Next to the link, list the permissions it requests and why. Server admins read that before they click, and it doubles as the answer when your bot later fails with 50013 and someone asks what it was granted.
• Granting more later is an admin task. If the bot needs a new permission after it is installed, the cleanest path is for a server admin to edit the bot's role in Server Settings, rather than expecting everyone to reinstall.

User-installed apps still respect the user's permissions where they are used. Discord's example: if a user runs a command from a channel where they cannot send messages, the app cannot respond with a non-ephemeral message there. If you add a new installation context to an existing app, update your commands' contexts too, or they will not appear in the new context.

When both contexts are enabled, the Discord Provided Link asks the user to choose "Add to server" or "Add to my apps".

The permissions value is a bitfield from Discord's permissions reference, sent as a decimal number. The flags most bots need:

Add the values you need: 1024 + 2048 + 16384 + 65536 = 84992. Note that Send Messages does not cover threads; add Send Messages in Threads if the bot replies inside threads.

Avoid Administrator. It bypasses every channel overwrite, which makes debugging "why can it post here" impossible and turns a leaked token into full server control. Discord also marks several moderation-level permissions (Administrator, Manage Server, Manage Webhooks and others) as requiring the owner account to use two-factor authentication when the server has server-wide 2FA enabled.

The integer only sets the permissions of the role Discord creates for the bot at install time. Server admins can change that role later, and channel overwrites can still deny things the role allows - which is where most post-invite errors come from.

Getting the bot into the server is half the job. The two errors that show up next:

Role hierarchy is the one the permissions integer cannot fix. Per Discord's docs, a bot can only assign roles, kick, ban or edit nicknames for members whose highest role is below the bot's highest role. A freshly invited bot's role sits near the bottom of the list, so "Manage Roles" in the invite does nothing until an admin drags the bot's role above the roles it should manage.

Diagnose instead of guessing:

1. Check the channel's permission overwrites for the bot's role and for @everyone.
2. Since October 30, 2026, Discord exposes computed permissions directly: GET /channels/{channel.id}/permissions/member/{user.id} with your bot's user ID returns its effective permissions in that channel (the call itself requires View Channels). Discord's change log lists matching guild and role variants.
3. Compare the result with the action you are attempting.

What changed recently: Discord is rolling out channel obfuscation for bots, mandatory from November 16, 2026. Channels a bot cannot view arrive over the Gateway with redacted fields (the name becomes ___hidden___ and a CHANNEL_OBFUSCATED flag is set), and GET /guilds/{guild.id}/channels omits them entirely. If your bot suddenly "loses" channels after an invite, it lacks View Channels there - the same root cause as 50001.

Two reality checks help when a user reports "the link is broken". First, confirm the client_id in the link is the Application ID of the app you think it is - dev and production apps get swapped constantly. Second, when someone you do not know asks for an invite link with Administrator to "test" something, be suspicious; the Discord account age checker decodes any user or app ID's creation date, which is a quick sanity check on brand-new accounts.

If the bot is in and online but not answering, our Discord bot not responding guide picks up from here, and the full code reference lives in the Discord error directory. For a business support bot you would rather configure than host, Conferbot's Discord integration walks you through the same install link from its dashboard.