Home › Resources

Discord Bot Privacy Policy: What Discord Requires and How to Write One

Published August 27, 2026 · Updated September 10, 2026

Discord requires every bot registered in the Developer Portal to have a privacy policy under its Developer Policy, and a working policy URL becomes an enforced gate once your bot needs verification -- triggered at 75 servers -- or applies for the App Directory. The policy has to describe what your bot actually does: which user IDs, guild IDs, and message content it processes, which privileged intents it uses and why, and what happens to any of it after the bot leaves a server. A generic document copied from a website's terms page, one that never names the bot, is one of the fastest ways to get a verification application rejected.

This guide covers exactly what Discord's Trust & Safety team checks during verification, the specific rejection scenarios developers run into and how to fix each one, what data your bot handles that goes undisclosed most often, how the 2026 split between bot verification and privileged intent review actually works, and what changes -- technically and legally -- once your bot crosses the 75-server line. Rather generate a policy than write one from scratch? Generate a privacy policy for free and host it at no cost.

Why Discord Requires a Privacy Policy for Your Bot

Discord's Developer Policy applies to every application registered in the Developer Portal, bots included, and requires a publicly accessible privacy policy that clearly and accurately describes how the application collects, uses, and shares user data. That obligation exists from the moment you create the application in the Developer Portal, not once the bot gets popular -- but Discord's enforcement mechanisms only bite at specific milestones.

Three moments make the policy non-negotiable in practice:

• Bot verification. Required once a bot reaches 75 servers (Discord lowered this threshold from 100 servers in its 2024 policy update). An unverified bot cannot accept invites to more servers past that point -- it is capped, not removed, but growth stops cold. The verification checklist requires a working privacy policy URL alongside Stripe identity verification for the team owner, a Terms of Service URL, and an accurate description of what the bot does.
• App Directory eligibility. To be listed and discoverable in Discord's App Directory, your application must already be verified and must have a connected, publicly accessible privacy policy and terms of service URL set in General Information -- a baseline eligibility gate that the Directory review checks again independently.
• Every other bot, technically. The Developer Policy carves out no exception for small or single-server bots. Enforcement is lighter below the verification threshold, but the obligation applies at any scale, and organizations deploying internal bots often require one regardless of what Discord enforces.

This is the same pattern Amazon uses for Alexa skill certification and Google uses for Chrome Web Store listings -- the platform gatekeeps distribution behind a policy check, and reviewers verify that the policy matches what the application actually does rather than just confirming the URL field is populated.

What Verification Checks

Bot verification is a one-time review performed by Discord's Trust & Safety team once your bot's server count reaches 75. It is separate from privileged intent review (covered below), and it is the process most developers mean when they say "getting my bot verified." The application happens from inside the Developer Portal, and Discord reviews the submission manually rather than approving it automatically.

The verification checklist covers five things:

• A valid Privacy Policy URL. Set in General Information, it must resolve over HTTPS, load without authentication, and contain an actual privacy policy -- not a homepage or a placeholder.
• A valid Terms of Service URL. Same field group, same accessibility bar. Discord checks both URLs together.
• An accurate bot description. The Description field in General Information has to describe what the bot actually does. A description that says "multipurpose utility bot" while the bot's real function is scraping message history for a third-party dataset will not pass.
• Justified privileged intent usage. If your bot has Message Content, Server Members, or Presence Intent enabled, the reviewer expects the bot's functionality to require it. Enabling Message Content on a bot that only responds to slash commands is a mismatch reviewers catch.
• Completed identity verification. The team owner must complete Discord's identity verification flow, handled through Stripe Identity, before the application can be approved. This confirms a real person or organization stands behind the bot.

Discord's review is manual, so turnaround is not instant -- start the process before you are actually blocked at 75 servers, since an unverified bot capped at that limit cannot accept new invites while the review is pending.

Where verification lives in the Developer Portal

Everything runs through discord.com/developers/applications. Select your application, and the left-hand tabs -- General Information, Bot, OAuth2, Installation, and others -- hold the fields verification checks. General Information carries Name, Description, Privacy Policy URL, Terms of Service URL, and Tags (up to five). The Bot tab holds the three privileged intent toggles under Privileged Gateway Intents. Verification pulls from both tabs -- the identity fields from General Information and the intent configuration from Bot.

Troubleshooting Verification Rejections

When Discord rejects a verification application, the notice is often terse. Below are the rejection scenarios developers run into most often, what triggers each, and how to fix it.

"Your application's privacy policy URL is missing or does not load correctly"

This is the single most common rejection reason. The Privacy Policy URL field in General Information is either empty, points to a URL that returns a non-200 status, redirects to an unrelated page, or requires a login. Discord's reviewers open the link directly -- a homepage with a "Privacy" link buried in the footer does not satisfy this, even if the actual policy is one click further in.

Fix: Paste a fully qualified https:// URL that resolves immediately to the policy text. Test it in a private browser window with no cookies or saved logins. If you have no stable hosting, generate and host a policy for free at a permanent URL and use that.

Policy doesn't describe the bot's actual practices

A generic, templated policy that never names the bot, or that describes data practices for a generic "application" rather than the specific bot under review, gets flagged. Reviewers cross-check the bot's name and stated functionality in the Developer Portal against the content of the linked policy. A moderation bot whose policy only mentions "cookies and website analytics" -- language recycled from a web template -- is an easy rejection.

Fix: Name the bot specifically in the policy, and make sure the data types listed (message content, member events, stored moderation records, whatever applies) match what the bot's code actually does.

Privileged intent usage not justified

Message Content Intent or Server Members Intent is enabled in the Bot tab, but nothing about the bot's stated functionality explains why it needs full message text or a member roster. This is a frequent rejection point for bots that enabled Message Content early (for a text-command prefix, say) and never migrated to slash commands, which do not require the intent at all.

Fix: Either write a clear justification tying each enabled intent to a specific feature, or disable intents the bot does not actually need. Slash commands eliminate the need for Message Content in most command-based bots entirely.

Identity verification incomplete

The team owner has not finished Discord's Stripe Identity verification flow. Verification cannot complete until this step is done, and it is easy to overlook since it is a separate flow from the application form itself.

Fix: Complete identity verification for the team owner account before or alongside submitting the verification application, not after.

Bot description doesn't match functionality

The Description field in General Information says something vague or inaccurate relative to what the bot's commands and event listeners actually do. Reviewers use this field as a first-pass sanity check against the rest of the application.

Fix: Rewrite the Description field to plainly state the bot's core functions -- moderation, music playback, ticketing, whatever applies -- in language that matches both the privacy policy and the bot's actual command set.

What Data a Discord Bot Collects

Most developers under-disclose because they think about what they store in a database, not what Discord sends their bot in the first place through the Gateway. Your policy needs to cover both layers.

• User IDs and usernames. Every message, reaction, or slash command carries the Discord user ID and current username of whoever triggered it -- a persistent identifier, so it is personal data before you ever save it anywhere.
• Guild and channel IDs. These identify where an interaction happened, and combined with a user ID reveal which servers someone uses your bot in.
• Message content, if you request the intent. Without MESSAGE_CONTENT, your bot only sees text it is mentioned in, a DM, or a slash command's own parameters. Enabled, every message in every visible channel passes through your code, logged or not.
• Voice state. Music and voice bots use the standard (non-privileged) GUILD_VOICE_STATES intent to know who joined or left a voice channel -- personal data, even though it skips the privileged-intent review entirely.
• Member lists and presence. GUILD_MEMBERS and GUILD_PRESENCES hand your bot a full member roster or users' online status -- far more than most bots need, and both are privileged.
• Join and leave events. Server Members Intent also delivers member join and leave events in real time -- useful for welcome messages and moderation logs, but a timestamped record of who joined or left which server and when.
• Logs. Console and error logs often contain user IDs or message snippets by accident -- data storage, whether intended or not, and something reviewers rarely think to check but should be disclosed if it happens.

The distinction that trips developers up: receiving data through the Gateway is processing, even when nothing touches a database. A fully stateless bot still needs a policy describing what it receives and why -- "we do not store data" is a valid disclosure, but only once you have accounted for what passes through memory first.

The Message Content Intent and Privileged Intents

Message Content, Server Members, and Presence are Discord's three privileged intents -- gateway access Discord does not hand out automatically, because each exposes data most server members would not expect a bot to see by default. Any bot using one needs to justify it, and the privacy policy is part of that justification during both verification and any later privileged intent review.

Where the toggles live

In the Developer Portal, open your application and click the Bot tab. Under Privileged Gateway Intents you will find three toggles: Presence Intent, Server Members Intent, and Message Content Intent. Each carries the same portal note: "If your bot is in 100 or more servers, this will require verification and approval." That copy is a holdover from the portal's UI and still references the old 100-server figure -- but the actual bot verification trigger for the application overall is 75 servers, and privileged intent review now runs on a separate track entirely, described below.

Bot verification vs. privileged intent review -- two different processes

Discord changed how privileged intent review works in 2026, and the change is easy to conflate with bot verification because both used to be tied to the same 100-server number. They are now separate:

• Bot verification is triggered at 75 servers, is a one-time process, and covers the whole application -- privacy policy, terms of service, identity verification, and a general check that privileged intents in use are justified.
• Privileged intent review is now triggered by unique user count across all of a bot's servers, not server count. As of 2026, the threshold is 10,000 unique users. Below that, you can self-toggle Message Content, Server Members, and Presence directly in the Bot tab with no application required. Past 10,000 users, the owner must apply, gets a 90-day window to submit the review, and approved bots must reapply annually to keep the intents enabled.

A bot can therefore be verified (past 75 servers) while still self-toggling privileged intents (under 10,000 unique users), or unverified (under 75 servers) while already needing privileged intent review (over 10,000 unique users concentrated in a handful of large servers). Track both numbers independently.

What this means for your privacy disclosure

None of this changes what data the intents expose -- only when Discord reviews the justification. Your policy obligation does not wait for either review: if MESSAGE_CONTENT is enabled, the policy needs a line explaining why the bot reads messages, whether content is stored or only processed in memory, and for how long, whether the bot has 50 users or 50,000. Bots that only need the intent to catch a legacy text-command prefix should migrate to slash commands instead, dropping the privileged intent -- and the disclosure burden, and the review risk -- entirely.

What Your Bot's Privacy Policy Must Include

Name the bot specifically -- a generic document that never mentions it by name is an easy rejection reason during verification review, as covered above. Beyond that, these sections cover what Discord and standard privacy law both expect.

• What data you collect, in plain terms rather than "we may collect certain information."
• Why you collect it. Tie each data type to a feature; if you cannot name a reason, stop collecting it.
• Who else receives it -- your host, your database provider, and any AI provider your bot calls if messages leave Discord for processing. Discord bars selling API data or handing it to data brokers -- say you do not, if true.
• How long you keep it. Real periods ("moderation logs, 90 days"), not "as long as necessary," and what happens to stored data when the bot is removed from a server.
• User rights. How someone gets a copy of their data or has it deleted, and which rights apply under GDPR and CCPA.
• Children's privacy. Discord's minimum age is 13 -- state the bot is not directed at under-13s.
• Contact and change notice. A working contact method and how you will announce policy changes.

Worked example: a moderation bot called "ModGuard"

Consider a moderation bot called "ModGuard" that scans messages for rule violations using the Message Content Intent, tracks member joins and leaves with the Server Members Intent, stores warning and ban history in PostgreSQL keyed to user ID and guild ID, and posts moderation logs to a webhook in a staff-only channel.

ModGuard's privacy policy needs to disclose, at minimum:

• Message content — every message in a server where ModGuard is active is scanned in memory against the server's rule set for auto-moderation. Content is not stored unless a violation is detected, in which case the offending message text is attached to the resulting moderation record.
• User IDs and guild IDs — stored alongside every warning or ban record in PostgreSQL, so history persists across sessions and can be reviewed by staff later.
• Member join and leave events — logged for 90 days to support raid detection and moderation review, then purged automatically.
• Moderation logs sent to a staff webhook — a Discord webhook posts each moderation action (warning issued, user banned, message removed) to a private staff channel, visible only to that server's staff.

The policy also needs a retention statement covering the full lifecycle: data tied to a given server is retained while ModGuard remains active in that server and deleted within 30 days of the bot being removed. It needs a children's disclaimer (not directed at users under 13, the age line a COPPA privacy policy is built around), GDPR and CCPA rights sections, and a contact method. Because ModGuard uses both Message Content and Server Members Intent, the privacy policy is also part of the justification Discord's reviewers check during verification and, once ModGuard crosses 10,000 unique users, during privileged intent review.

The same process applies broadly to writing a privacy policy for any app: audit what you actually collect, map each item to a purpose, name every third party, and set a real retention period.

What Changes Once Your Bot Passes 75 Servers

Crossing 75 servers is not just a number on a dashboard -- it triggers a set of concrete requirements and unlocks a set of concrete benefits, and developers who plan for it ahead of time avoid getting capped mid-growth.

• Verification becomes mandatory to keep growing. Once a bot hits 75 servers without being verified, it stops accepting invites to new servers. Existing installs keep working; new ones are blocked until verification completes.
• The Privacy Policy URL becomes enforced and visible. Once verified, the URL set in General Information is displayed on the bot's public profile, where any server admin considering an install can read it before inviting the bot.
• The Terms of Service URL becomes enforced the same way. Both URLs are checked together during verification and both surface publicly afterward.
• Team owner identity verification is required. The Stripe Identity flow for the team owner must be completed as part of verification -- it is not optional past this point.
• Privileged intents come under potential review. Verification itself checks that any enabled privileged intent is justified. Separately, if the bot's unique user count also crosses 10,000, the annual privileged intent review process kicks in regardless of server count.
• App Directory eligibility opens up. Verification is a prerequisite for App Directory listing, but it is not automatic -- a separate application and review is required, and the privacy policy and terms of service URLs are checked again as part of that review.
• Higher rate limits may become available. Verified bots are eligible for increased API rate limits compared to unverified applications, which matters for bots operating at scale across many servers.
• A verified badge appears on the bot's profile. Visible to every server member, it signals to admins and users that the bot passed Discord's review.

Compliance obligations scale with server count in practice even though the legal requirement does not change: more servers means more jurisdictions your users are sitting in, more data volume moving through your bot, and a proportionally higher cost if your policy turns out to be inaccurate during a later re-review.

How to Generate a Discord Bot Privacy Policy

Writing a Discord bot privacy policy from scratch means auditing every Gateway event your bot subscribes to, mapping each privileged intent to a specific feature, documenting your database schema well enough to describe retention accurately, and formatting the result into something that survives a Trust & Safety reviewer's read-through. For a bot using Message Content and Server Members Intent with a real database behind it, that is real work.

A privacy policy generator compresses this into a guided questionnaire: which platform (Discord bot, alongside web or mobile if you have a companion app), which data types your bot processes (user IDs, guild IDs, message content, voice state, member events), which third parties you send data to (your host, your database, any AI API), and which regulations apply to your user base. The output is a policy with the right disclosure language for each selection, hosted at a permanent HTTPS URL you paste straight into the Developer Portal's Privacy Policy URL field.

Generator vs. template vs. manual drafting

• Generator (fastest for bots with real data flows). Best once your bot uses a privileged intent, stores anything in a database, or calls a third-party API. A free privacy policy generator walks through each data category and produces a submission-ready policy with hosting included -- useful when you need to clear verification without hiring a lawyer.
• Template (fine for simple bots). If your bot has no privileged intents, no database, and no third-party calls, the sample policy below works after you fill in the brackets and delete what does not apply.
• Manual drafting (for edge cases). Bots that process payments, biometric data, or health information, or that are aimed at users under 13, may need custom legal language beyond what a generator or template covers. Use the required sections list above as a starting checklist and involve a privacy attorney.

Whatever approach you take, check the finished policy against the verification checklist above before submitting: correct bot name, every enabled intent justified and disclosed, and a URL that loads without authentication on both mobile and desktop.

Sample Discord Bot Privacy Policy You Can Copy

A template for a fictional bot, "[Your Bot Name]." Copy it, fill in the brackets, and delete anything that does not apply.

Bots with payments or AI integrations need a dedicated section for each. Want a policy built from your bot's actual practices instead? Build one for free with the generator.

Privacy Policies for Private and Team-Only Bots

Not every Discord bot is headed for the App Directory or a large public server base. Three categories cover most bots that never see verification at all: internal team tools never invited to an external server, bots that stay intentionally small and never approach 75 servers, and bots still in active testing or development.

Internal team tools

A bot built to run in a single company's Discord server -- handling deploy notifications, standup reminders, or internal ticketing -- never gets invited anywhere else and never approaches the verification threshold. Discord does not require or check a privacy policy for a bot like this at any point in its lifecycle, since it never triggers verification or Directory review.

That said, organizational compliance may require one regardless of what Discord enforces. If the bot processes employee data -- names, Discord IDs, message content used for internal analytics -- your company's own data-handling policies, especially under GDPR if any team members are in the EU, may obligate you to document the bot's practices internally even without a public-facing requirement from Discord.

Small bots that stay under 75 servers by design

Some bots are built for a niche community and never intend to scale past a handful of servers. Discord does not enforce a privacy policy requirement for bots that never cross 75 servers, since verification simply never triggers. The Developer Policy still technically requires a policy at any scale, but in practice enforcement is limited to the moments described earlier in this guide: verification, App Directory listing, and (separately) privileged intent review at 10,000 unique users.

Testing and development bots

A bot running only in your own test server while you build it out has no meaningful audience and no enforcement trigger. Once you start inviting real servers, though, is the right moment to write the policy -- not after you are already capped at 75 servers and rushing through verification. Drafting it while the data flows are still fresh in your head is faster and more accurate than reconstructing them later.

Whichever category your bot falls into, having a policy in place before you need one costs little and avoids the scramble that comes with racing a verification deadline once your bot's growth outpaces your paperwork.

Hosting Your Policy and Adding It to the Developer Portal

The policy needs a stable, public URL. Google Docs, Notion pages, and Pastebin links are a poor fit -- they can change, go private, or disappear, exactly what Discord's reviewers watch for. Three options hold up:

• Your bot's own site -- a path like yourbotname.com/privacy. Full control, no third-party dependency.
• A free generated policy -- if you have no website, generate and host one for free and link straight to the permanent URL.
• GitHub Pages -- a static HTML page in a public repo, common for open-source bots, as long as it renders without a GitHub login.

Where the fields live in the Developer Portal

Open discord.com/developers/applications and select your application. The General Information tab holds the fields that matter here: Name, Description, Privacy Policy URL, Terms of Service URL, and Tags (up to five). Paste the full URL, including https://, into Privacy Policy URL, and do the same for Terms of Service URL if you have one -- both are checked together during verification and both later appear on your bot's public profile once verified.

Separately, the Bot tab holds the Privileged Gateway Intents section, where the Presence, Server Members, and Message Content toggles live -- this is where you actually enable the intents your policy needs to describe. The Installation tab configures OAuth2 scopes and bot permissions for the invite link, which is worth double-checking against your policy too: a bot requesting the administrator permission or a broad OAuth2 scope set should have a policy that justifies why.

These URLs also surface during your bot's OAuth2 authorization flow, and they are the same fields verification and Directory reviewers check. If your data practices change, update the policy and bump the modified date before your next reapplication or Directory review, not after.

Frequently Asked Questions