What Discord’s Terms Actually Allow You to Build

Three documents govern what you may build on Discord, they cover different things, and almost every question people ask about what is allowed is answered in one of them. This is a plain-language map, not legal advice.

Three documents, three scopes

The Terms of Service govern your use of Discord as a user and, by extension, how you may run a server. The Developer Terms of Service govern building applications on the API. The Developer Policy adds the specific rules about data: what an app may collect, how long it may keep it, and what it must do when a user asks.

If you run a community you are bound by the first. If you commission a bot, whoever builds it is bound by all three, and the obligations do not transfer to them just because you paid.

Selling access to a server

Charging for a role or for entry is permitted within Discord’s monetisation rules, but those rules are specific about what may be sold and how it may be presented. Read the Monetization Policy before designing a tier rather than after — the constraints are on the substance of what you offer, not just on the payment mechanism.

The operational point that gets missed: monetisation privileges depend on the server remaining in good standing. A community guidelines violation does not only cost you a warning, it can cost you the revenue arrangement.

What a bot may store

The Developer Policy is the document to read here, and its shape is consistent: collect what your stated function needs, keep it only as long as that function requires, secure it, and delete it when a user or a server asks. Bulk collection “because it might be useful” is exactly what the policy is written against.

Message content deserves particular care, because it is both privileged at the API level and sensitive at the policy level. A bot that stores message text needs a specific reason and a short retention period, and it should expect that reason to be examined during verification.

Scraping and exports

Reading the API with a bot that a server has installed is the sanctioned path. Automating a user account to collect data is not — self-bots are prohibited, and the prohibition is enforced against the account rather than the code.

This matters for a very ordinary request: migrating a community and wanting to bring the history. The supported answer is to keep the server and restructure it, not to export and re-import conversations.

Reselling and white-labelling

Building a bot for a client and handing it over is ordinary work. Reselling the same application to many clients turns it into a public app with the obligations that come with scale — verification, intent approval, sharding, and a support burden. Those are different products with different economics, and treating one as the other is a common way to get stuck.

For a client the practical question is simpler: do I own the code, or a licence to use something the agency also sells elsewhere? Both are legitimate. Only one lets you take it with you.

Deletion is an obligation, not a feature

When a user or a server asks an app to delete their data, the app has to be able to do it. That requirement decides how the bot must be built — data keyed by user and server identifier, with an erase path — and it is much cheaper as an initial design decision than as a retrofit.

Where the risk actually sits

Enforcement is account-level and platform-level. The realistic consequences are an application losing verification or intents, a server losing monetisation, or an account being actioned. There is rarely a warning shot for a bot that has been quietly storing more than it declared.

Which is the argument for reading the three documents once, at the start of a project, and writing down what the system stores and why. That page is also most of what you need for a data protection record, so it pays for itself twice.

Age and content rules shape the design

Discord has a minimum age for its service and separate rules for age-restricted content, including which channels may carry it and who may see them. For a community operator these are not abstract policies; they decide whether a channel needs an age gate, and whether a feature you were planning is viable at all.

The design consequence is to decide early. Retrofitting an age gate onto a community that has been running without one means auditing existing members, which is far more disruptive than setting the channel flag on day one.

Verification badges, and what they do not mean

A verified badge on an application signals that Discord has checked the developer’s identity and reviewed the requested intents. It does not certify that the bot is well built, that it stores data responsibly, or that it will still be maintained next year.

Treat it the way you would treat any credential: as evidence about the process, not about the product. The questions that tell you whether a bot is safe to install are still the same three — privacy policy, retention period, deletion path.

What to put in writing with an agency

Four clauses do most of the work. Who owns the source code of anything custom, and that a copy is delivered. Which application and developer account the bot runs under, and who controls it. What the bot stores and for how long. And what happens to the hosting if the relationship ends.

That third clause is the one clients almost never ask for and later wish they had, because it is also the answer they need when somebody asks them what their community stores about its members.

The one page worth keeping

A single document listing every system that touches member data: the bot and what it stores, any third-party bot and its policy, where each runs, the retention period, and who to contact. Half a page for most communities.

It answers a data protection question, a due-diligence question and a handover question at once, and it takes an afternoon to write while the project is fresh. Reconstructed two years later from a running system, it takes a week.