Discord Username Checker - Availability, Bulk & Fast

For developers, bots and handle hunters: whether each Discord username is available, taken or invalid (with Discord's own reason code and message), plus the time it was checked - in a run of up to 1,000 names, or one name per HTTP request in Standby mode. Measured with this Actor on Apify: 100 names in 64 s and 300 names in 281 s in one run (2026-09-23, every name answered); in Standby mode 0.33 - 0.92 s per name once the Standby run is up (2026-09-29, 51 requests from a client in Japan, see Standby mode). A name Discord could not answer is never reported as available.

Export as JSON, CSV or Excel.

Unofficial. Public data only. Not affiliated with, endorsed by or connected to Discord Inc.

---

What it does

You give it usernames. It asks Discord the same question the sign-up page asks ("is this username taken?") and returns one row per name.

{
  "usernames": ["elonmusk", "quiet.harbor.7319", "a", "discord_fan"]
}

Rows returned for that input (real answers, 2026-09-23):

[
  { "username": "elonmusk", "taken": true, "available": false, "status": "taken", "reason": null, "reasonMessage": null, "inputUsername": "elonmusk", "checkedAt": "2026-09-23T11:11:04.865Z", "source": "discord" },
  { "username": "quiet.harbor.7319", "taken": false, "available": true, "status": "available", "reason": null, "reasonMessage": null, "inputUsername": "quiet.harbor.7319", "checkedAt": "2026-09-23T11:11:04.360Z", "source": "discord" },
  { "username": "a", "taken": null, "available": false, "status": "invalid", "reason": "BASE_TYPE_BAD_LENGTH", "reasonMessage": "Must be between 2 and 32 in length.", "inputUsername": "a", "checkedAt": "2026-09-23T11:11:05.845Z", "source": "discord" },
  { "username": "discord_fan", "taken": null, "available": false, "status": "invalid", "reason": "USERNAME_INVALID_CONTAINS", "reasonMessage": "Username cannot contain \"discord\"", "inputUsername": "discord_fan", "checkedAt": "2026-09-23T11:11:07.346Z", "source": "discord" }
]

The first three columns - username, taken, available - have the same names and meaning as in other Discord username checkers, so a script that reads those three fields from the dataset does not have to rename them. Results are written to the default dataset only (nothing is written to the key-value store). You can also send a single name in a field called username instead of a list.

Why this one

• One name or many, same Actor. Send {"username": "name"} for one check, or usernames with up to 1,000 names. Other checkers take one name per run (you pay the start-up time for every name) or a list only.
• Standby mode for scripts that check names all day. GET /check?username=<name> on the Actor's Standby URL answers with one JSON object, without starting a new run for every name. Same price, same fields.
• Invalid names come back with Discord's reason, not just "not available": too short or too long (BASE_TYPE_BAD_LENGTH), characters Discord does not allow (USERNAME_INVALID_CHARACTERS), repeated dots (USERNAME_INVALID_REPEATING_DOTS), or a word Discord reserves such as "discord", "clyde" or "wumpus" (USERNAME_INVALID_CONTAINS). These are the reason codes seen in the measurements for this README; Discord may add others, and whatever it sends is passed through.
• Every row says when it was checked (checkedAt, UTC). Availability changes the moment someone registers the name.
• It does not guess. If Discord rate-limits a name after the retries, blocks the request, or answers with something that cannot be read, that name comes back as a free row with available: null, taken: null and a note saying why. It is never counted as available.

Input

Field	What it does
usernames	List of usernames, one per line (commas also split). A leading @ is removed and upper/lower case is ignored - Discord ignores case too (ElonMusk and elonmusk got the same answer). A space inside a name is kept and sent as typed, and Discord answers invalid. The same name is checked and charged once. Up to 1,000 per run.
username	One username, for tools that send a single name in a field called username. Checked first, together with the list.

If both are empty, the example names elonmusk and quiet.harbor.7319 are checked and every row says so in inputUsername.

Output columns

Column	Meaning
username	The name that was sent to Discord (leading @ removed, lower case).
taken	true if Discord says the name is in use, false if it is free, null for invalid names and free rows.
available	true only when Discord said the name is free. false for taken and invalid names. null on free rows (no answer).
status	available, taken or invalid on charged rows. Free rows: rate-limited, blocked, unreadable, invalid-input, duplicate, budget-reached, not-checked.
reason	Discord's reason code for an invalid name (several are joined with commas).
reasonMessage	Discord's own sentence for an invalid name.
inputUsername	The name exactly as you typed it.
checkedAt	When the answer came back (ISO 8601, UTC).
note	Free rows only: why there is no answer, and whether anything was charged (it never is).
source	Always discord.

Speed and cost of one check

Measured on Apify with the default 128 MB of memory (2026-09-23, and 2026-09-29 for the 41 one-name runs):

Run	Time of the run	Time from the API call until the result is ready
One name, 41 runs through run-sync-get-dataset-items on 2026-09-29 (called from Japan)	1.6 - 6.4 s, median 2.9 s; one run took 20.5 s	1.9 - 6.7 s, median 3.4 s; that one took 20.9 s
One name in Standby mode (51 requests after the first, 2026-09-29, called from Japan)	no new run per name	0.33 - 0.92 s
One name while the datacenter proxy addresses were rate-limited (3 new sessions, answered on residential)	6.6 s	8.4 s
38 names	24.6 s	26.4 s
100 names	64.4 s (about 0.64 s per name, 0 rate limits)	68.4 s
300 names, right after a heavy test had used up most datacenter proxy addresses	280.7 s (about 0.94 s per name; 42 retries through other proxy sessions, every name answered)	282.5 s

A one-name run costs $0.005 - the price of one checked name - and nothing else. Most of a one-name run is Apify starting the run. More memory did not clearly help: 512 MB took 1.8 - 3.6 s (5 runs) and 1,024 MB 1.7 - 5.5 s (8 runs), inside the spread of the 128 MB runs. If you check names one at a time all day, use Standby mode.

Standby mode: one name per HTTP request

For scripts, bots and monitors that check one name at a time, again and again. In Standby mode the Actor keeps a run open and answers HTTP requests, so there is no new run per name.

curl -H "Authorization: Bearer <YOUR_APIFY_TOKEN>" \
  "https://neverempty--discord-username-checker.apify.actor/check?username=elonmusk"

The answer is one JSON object with the same fields as a dataset row of a normal run:

{ "username": "elonmusk", "taken": true, "available": false, "status": "taken", "reason": null, "reasonMessage": null, "inputUsername": "elonmusk", "checkedAt": "2026-09-29T02:54:34.101Z", "source": "discord" }

HTTP status	Meaning	Charged
200	Discord answered: available, taken or invalid (with Discord's reason)	Yes: one username-checked event, $0.005
400	No name, more than one username parameter, a comma, semicolon or line break in the value, or not a name. Nothing is sent to Discord.	No
402	The maximum total charge of the Standby run was reached	No
502	Discord blocked the request, answered with a verification page, or its answer could not be read	No
503	Discord still rate-limited the name after the retries, or the request waited more than 4 minutes in line behind other requests to the same Standby run (then it is not sent to Discord)	No
504	Discord's answer came back more than 4 minutes after the request, too late to return safely	No
404 / 405	Unknown path, or a method other than GET	No
500	Internal error	No, unless the error happened while the charge was being recorded: then x-charged-events is unknown

Every response has the header x-charged-events: 1 when that request was charged, 0 when it was not (unknown only in the 500 case above). The bodies of 400, 402, 502, 503 and 504 are the same free rows as in a normal run, with available: null, taken: null and a note; 404, 405 and 500 answer with an error field.

• Speed, measured on 2026-09-29 from a client in Japan: a request that has to start a Standby run took 3.1 - 6.0 s (6 cold starts); on a running Standby run (256 MB), 51 requests in a row took 0.33 - 0.92 s each. A Standby run stops after 60 seconds without requests, and the next request starts a new one.
• One name per request. Send username once. A leading @ is removed and upper/lower case is ignored, as in a normal run.
• Requests to Discord from one Standby run go one at a time, with the same short pause, the same retries through new proxy sessions and the same "no verification page is ever solved" rule as a normal run. Requests you send at the same moment to the same run wait in line. One Standby run takes up to 4 requests at once; if you send more at the same moment, Apify starts another Standby run (with its own start-up time), and different runs send to Discord in parallel.
• Time limits. When Discord rate-limits, a response can take longer (retries through new proxy sessions). Apify ends any Standby response after 5 minutes, so the Actor gives up after 4 minutes: a request still waiting in line is not sent (503), and an answer that comes back later is not returned and not charged (504).
• Closing the connection early does not stop the check. Apify does not pass a closed connection on to the Actor, so if your client stops waiting after the request reached the Actor, the name can still be checked and charged. Give your client a timeout of at least 4 minutes, or accept that a request you abandon may be charged.
• The Standby URL needs your Apify API token. The Authorization: Bearer header keeps it out of server logs; a token= query parameter also works.

Pricing

Pay per event: $5.00 per 1,000 usernames checked ($0.005 per name), and nothing else - no start fee. You are charged for a name only when Discord answered for it: available, taken or invalid. Rate-limited, blocked and unreadable names, input that is not a name, repeated names and anything the run's maximum total charge did not cover come back as free rows.

If you set a maximum total charge for the run, the Actor checks only as many names as that limit can pay for. The rest are not sent to Discord, and one free row says how many were left.

Rate limits and how the requests are made

• The Actor sends one request per name to https://discord.com/api/v9/unique-username/username-attempt-unauthed - the endpoint Discord's own sign-up page uses to say whether a name is taken. No account, login, token or cookie is used.
• It does not hammer Discord. Within a run, names are checked one after another with a short pause, never in parallel. When Discord says "wait N seconds" and N is 3 seconds or less, the Actor waits that long on the same connection. When Discord asks for a longer wait, the Actor does not wait it out and does not ask again through that proxy session: the name is retried through a new Apify Proxy session (up to three datacenter sessions, then residential). Apify's pool of addresses is finite, so in a long run an address can come back later through another session. After 5 attempts the name comes back as a free rate-limited row. One proxy session is used for at most 15 names in a row, and after a name needed a residential session the next 25 names start on residential.
• It stops instead of spinning. If 10 names in a row get no answer (rate limits or blocks on every session tried), or the run is 30 seconds from its timeout, the Actor stops sending and one free not-checked row says how many names were left. If a run has no Apify Proxy at all, rate-limited names are not retried and the log says so.
• Verification pages (CAPTCHA) are never solved or bypassed. If Discord answers with one, the name comes back as a free blocked row.
• Requests go through Apify Proxy. Measured on 2026-09-23 with a separate probe on Apify: from Apify's plain server addresses (no proxy) Discord answered 19 of 25 requests with a rate limit asking for a wait of 8 to 21 minutes; through Apify's datacenter proxy it answered 96 of 96, spaced 1.5 seconds apart. With this Actor, one proxy address was rate-limited after about 20 names in a row, and a 1,000-name run made right after a day of testing used up the datacenter addresses after about 270 names and slowed to 6 - 7 s per name (538 names answered before the 30-minute timeout). That run is why the Actor now moves to residential sooner and stops before the timeout; the 300-name run in the table above came after the change.
• Discord's robots.txt disallows /api/ for crawlers, and this endpoint is under /api/. The Actor is not a crawler: it sends only the names you give it, one request each, and follows no links.

Limits

• Up to 1,000 names per run. Split longer lists across runs. Speed depends on how many proxy addresses Discord is rate-limiting at the moment (0.64 - 0.94 s per name in the runs above, 6 - 7 s per name in the worst run measured); names that do not fit before the run's timeout come back in the free not-checked row.
• An available answer means "free at checkedAt". Anyone can register it a second later.
• Discord only answers for the new unique usernames (no #1234 discriminator). A name with # in it comes back as invalid.
• If Discord changes or closes this endpoint, or starts requiring a verification step for it, the Actor stops returning answers (you get free rows saying so) rather than guessing.

FAQ

Is a rate-limited name charged? No. Only names Discord answered for are charged.

Can I check the same name every few minutes? Yes - each run (or each Standby request) is independent and charged per name checked. For frequent single-name checks, Standby mode avoids starting a run each time. Keep the interval reasonable; checking faster does not make Discord answer differently.

Why is taken null for an invalid name? Discord did not say whether it is taken - it said the name cannot be registered at all. available is false because you cannot claim it.