Publishing your first bot

What has to be finished before you submit

The most common feedback on a rejection is not "this bot is bad", it is "the bot was unreachable". Before submitting, walk through these four points — twenty minutes here saves you a round trip through the queue.

The bot has to be online and stay online. We invite it to a server and check whether it responds. A bot that only runs while you are at your computer will fail. If you do not yet have somewhere it runs permanently, this is the moment to sort that out.

A help command has to exist. It is the only route by which anyone discovers what your bot does. A /help listing the main commands with one sentence each is entirely sufficient.

The support server has to be real. We check that it exists and that somebody is in it. An invite link to an empty server is worse than no link at all.

Permissions have to match the features. This is the most common reason we come back with questions. If your invite requests Administrator, we need a justification — and "it was easier" is not one.

Descriptions: two languages, one standard

We are bilingual, and that applies to listings. You supply a German and an English version of both the short and the long description. If one is missing we show the other with a note — but you lose half your search visibility doing that.

The short description gets 160 characters. It appears in lists, in search results and in the meta description. Write what the bot does, not how great it is. "Moderation with logging, automod and graduated warnings" outperforms "The best moderation bot for your server!".

The long description is Markdown. What helps: a list of core commands with one line each, and a section explaining which permissions are needed for what. What does not help: rows of asterisks, emoji as bullet points, and a wall of capital letters.

Proving ownership

Discord offers no public way to check who owns an application. We solve it with a second OAuth2 flow requesting the applications.commands.update scope on your application ID. Only an owner, or a team member with sufficient rights, can grant that consent.

In practice: one click, one confirmation at Discord, done. If it fails — for instance because the application belongs to a team where your role is too limited — there is a second route using a token you temporarily place in your application's description in the developer portal.

What happens during review

After submission, automated checks run first. We decompose the invite URL, check every link for reachability and reputation, look for duplicates, and verify the support server exists. Anything failing hard comes straight back to you with a concrete reason — your listing never reaches the queue in that case.

Then comes the human review. A person invites your bot to a server, tries the advertised core features and works through a checklist. That usually takes under ten minutes when the bot does what the description says.

Three outcomes are possible: approved, changes requested, rejected. The latter two come with a reason that says what to do. "Changes requested" is not a no — you fix it and resubmit the same submission.

After approval

Your listing is public, and from then on something else matters: the server count arrives through our API from you. Report it regularly — it is one of the sort orders, and a bot reporting zero servers sits at the bottom.

Edit descriptions freely. Every change to a published bot creates a new submission, but the previous version stays live until the new one is approved. Pure numbers submitted through the API pass through without review.