Detect Which Names Discord Reserves or Rejects
Find out which candidate names Discord won't issue at all — reserved and policy-rejected names surface as error verdicts.

Some names aren't taken — they're not issuable. The verdict distinguishes the two. Thirdwatch's Discord Username Checker checks whether Discord usernames are taken or available — in bulk — returning a clean verdict per name.
Skip the setup: Run this as a ready-to-go task on Apify — pre-loaded with the configuration from this guide.
Why detect reserved names
'Taken' and 'not issuable' are different outcomes. System names, reserved words and policy-blocked strings come back rejected regardless of who asked.
The checker surfaces those as error verdicts — a distinct signal from taken.
The checker asks Discord directly for each candidate name and reports taken, available, or invalid — a bulk answer to a question the app only answers one name at a time.
How does this compare to the alternatives?
| Approach | Cost model | Coverage | Effort |
|---|---|---|---|
| Try registering the name | Free | One name at a time | Risks claiming names you test |
| Ask around / guess | Free | Unreliable | No systematic answer |
| Thirdwatch Discord Username Checker | Pay per check | Bulk lists | Paste names, run |
Why this Actor
- Bulk input — a candidate list becomes a verdict list.
- Clear outcomes per name: taken, available, or invalid/reserved.
- Proxy handling built in — shared-IP checks get rate-limited, managed rotation avoids it.
- Cheap enough to run a full naming shortlist.
- Saves accidentally registering a name while testing it.
How to do it in 3 steps
Step 1: Configure the input
Set the inputs as shown below — usernames takes the targets, plain usernames without @; proxyCountry routes checks through managed proxy rotation — Discord aggressively rate-limits datacenter IPs.
Step 2: Run the Actor
Run it from the console, the API, or the linked saved task. One dataset row is written per username.
Step 3: Use the output
Each row carries the username plus taken/available verdicts, or an error field when Discord rejected the check.
{
"usernames": [
"admin",
"discord",
"everyone"
],
"proxyCountry": "US"
}Each dataset row looks like:
{
"username": "mybrand",
"taken": false,
"available": true
}What to watch for
Discord's rate limits are strict — always set proxyCountry, and retry error rows rather than reading them as a verdict. Availability is point-in-time.
Related use cases
- Check Whether Your Brand Name Is Free on Discord
- Check a Bulk List of Discord Usernames for Availability
- Scan Name Options Before Launching a Discord Community
- Audit Your Handle Variants for Squatting on Discord
- All Thirdwatch use-case guides
Run the Discord Username Checker on Apify Store — pay per result, free to try, no credit card to test.
Frequently asked questions
Why do I need the proxy option?
Discord rate-limits datacenter IPs aggressively — without managed proxy rotation almost every check returns a 429. `proxyCountry` (default US) routes around it.
What does an `error` row mean?
Either a rate limit (retry it) or a name Discord reserves/rejects — reserved names are neither taken nor available.
Can I check names with periods or underscores?
Yes — pass the exact username string; Discord's own validation decides what's valid.
Is `available` a guarantee?
It's the API's verdict at check time — names can be claimed at any moment, so register promptly.
How many names per run?
As many as you like — each name is one row. Keep lists reasonable to stay under rate limits even vimanaged proxy rotations.
Does it check server names or just user names?
Usernames — the account-level handle introduced with Discord's new naming system.
Related
100 free credits, no credit card.
About 30 real searches. Add the MCP to Claude or Cursor in two minutes.