UltraFast Discord Username Checker

UltraFast Discord Username Checker checks candidate Discord usernames in bulk and writes point-in-time availability results to an Apify dataset.

It does not require a Discord login, password, user token, or browser session from your Discord account.

What does this Actor do?

• Checks up to 5,000 unique usernames in one public run.
• Accepts pasted text in Apify Console and array input through raw API calls.
• Normalizes and deduplicates the input before checking.
• Uses an Actor-managed residential proxy profile for public runs when the required operator credential or rotating template is configured.
• Stores available usernames and actionable diagnostic results in the default dataset.
• Charges the successful-check event only for conclusive available and taken results when that pricing model is active.

Availability is observed at check time. A username can be claimed after a run finishes, so recheck important names immediately before acting on them.

Input

Apify Console

Paste one username per line into Usernames:

{
  "usernamesText": "samplecheck0001\nsamplecheck0002\nsamplecheck0003"
}

Commas also work as separators. Blank lines and lines beginning with # are ignored.

Raw API input

The runtime also accepts a usernames array in raw Actor input:

{
  "usernames": [
    "samplecheck0001",
    "samplecheck0002",
    "samplecheck0003"
  ]
}

The array is an API compatibility feature; the public Console form exposes usernamesText.

Normalization and limits

Before any Discord requests are sent, the Actor:

1. Trims surrounding whitespace.
2. Converts usernames to lowercase.
3. Removes duplicates while preserving the first occurrence.
4. Rejects an empty list.
5. Rejects public input containing more than 5,000 unique usernames.

An over-limit input fails before Discord checking, billing, dataset publication, or webhook delivery. Split larger lists into runs of at most 5,000 unique names.

Public callers cannot override the Actor's protected proxy, routing, Discord endpoint, fingerprint, output, or webhook settings by adding hidden JSON fields. Advanced runtime settings are reserved for trusted owner runs.

Dataset output

Each stored item uses this shape:

Field	Type	Description
username	string	Normalized username associated with the result.
available	boolean	true only when Discord returned a conclusive available response.
status	string	Terminal classification or diagnostic status.
statusCode	integer	Discord HTTP status when one was received; otherwise 0.
attempts	integer	Number of Discord request attempts made for this username.
checkedAt	string	UTC timestamp for the final result.
error	string	Optional diagnostic details for non-successful checks.

Example available result:

{
  "username": "samplecheck0001",
  "available": true,
  "status": "available",
  "statusCode": 200,
  "attempts": 1,
  "checkedAt": "2026-09-01T12:00:00Z"
}

Which results appear in a public dataset?

Public runs enforce outputMode: "available_only". The Actor still retains conclusive taken results internally for billing and summary counters, but does not store those rows in the public dataset.

Status	Meaning	Billable successful check?	Stored in the public dataset?
available	Discord conclusively reported the username as available.	Yes	Yes
taken	Discord conclusively reported the username as taken.	Yes	No
invalid_format	Discord rejected the username format.	No	No
retry_exhausted	A retryable request did not become conclusive within the attempt limit.	No	Yes
rate_limit_stalled	Per-username rate-limit recovery was exhausted.	No	Yes
deferred_rate_limit	Checking stopped because a shared cooldown could not safely finish in time.	No	Yes
deferred_route_capacity	Safe route capacity was unavailable or the checking deadline ended before verification.	No	Yes
failed	The Actor could not produce a conclusive result for this username.	No	Yes
budget_exhausted	The username was not checked because the run charge limit could not admit it.	No	Yes

Never interpret a deferred, failed, stalled, retry-exhausted, or budget-exhausted row as available or taken. Retry those usernames in a later run.

If any checked username remains unresolved, the Actor can finish with a failed run status after publishing available and diagnostic rows. Always inspect the dataset before retrying the unresolved subset.

Pricing and maximum charge

The pricing information attached to the active run is authoritative for billing. Consult the Actor's Pricing tab for the currently published prices; the repository does not hard-code public tier prices.

Under the successful-check pay-per-event model:

• available and taken are successful-check events.
• Invalid, deferred, failed, retry-exhausted, stalled, and budget-exhausted outcomes are not successful-check events.
• Retries do not create additional successful-check events.

External runs using this pricing model require a positive maxTotalChargeUsd in the run options. Before checking, the Actor resolves the active event price and conservatively limits how many input positions can fit within the remaining charge allowance. Any remaining names receive budget_exhausted without a Discord request.

Admission uses the input order. A non-billable result near the start of the admitted prefix does not cause a later budget-exhausted username to be backfilled into the same run.

Billing is settled and verified before dataset and webhook publication. If billing cannot be verified, the Actor fails closed and does not publish results. A later dataset API failure can still interrupt publication after a verified charge; report the run ID to support so the run can be reconciled.

Enforced public runtime profile

Public runs use a bounded route-capacity profile. These settings describe the current implementation; they are not speed, cost, or availability guarantees.

Setting	Public behavior
Maximum unique usernames	5,000
Output mode	available_only
Discord API	https://discord.com, API v10
Proxy profile	Actor-managed residential routes, Netherlands, rotating sessions, when operator proxy configuration is present
Active route concurrency	ceil(unique usernames / 15), minimum 1
Reserve routes	ceil(active routes × 25%)
Verified results per proxy session	At most 15
Request timeout	10 seconds
Checking phase	Up to 60 seconds, shortened if the overall run deadline is closer
Rate-limit recovery attempts per username	At most 10
Route-attempt safety guard	At least 6,500; scales to the total declared route capacity for larger inventories
Physical proxy-session guard	Aligned with the route-attempt guard so safe session rotation cannot stop earlier than the request budget
Browser TLS, browser bootstrap, HTTP/3	Disabled
Direct and caller-supplied proxy routes	Disabled

For 5,000 unique usernames, the current formula produces 334 active routes and 84 reserve routes, for 418 declared routes in total. Actual throughput varies with Discord responses, proxy availability, rate limits, and Apify platform conditions.

Proxy credentials and validation are managed by the Actor owner. When proxying is enabled, a public run fails before checking if the configured route cannot be authenticated or used. Without an operator proxy configuration, public callers cannot supply a replacement route and the run cannot produce normal route-capacity results.

How a run is processed

1. The Actor loads, normalizes, deduplicates, and validates the input.
2. It applies the trusted public runtime policy and calculates the charge allowance.
3. When proxying is configured, it validates the proxy route before scheduling checks.
4. It classifies each admitted username without treating ambiguous responses as availability answers.
5. It creates budget_exhausted rows for input outside the charge allowance.
6. It verifies successful-check billing, then publishes the permitted dataset rows.
7. It sends available-name webhook notifications as a separate best-effort operation.

The Apify dataset is the primary output. Webhook delivery is not guaranteed and webhook failure does not remove an already published dataset.

Data handling

• When proxying is enabled, submitted usernames are sent to Discord through the configured proxy routes.
• Permitted results are stored in the run's default Apify dataset.
• Available usernames may also be sent to the Actor owner's configured Discord webhook.
• The Actor does not request Discord account credentials from users.

Do not submit confidential username lists. Do not place passwords, tokens, webhook URLs, or credential-bearing proxy URLs in public tasks, shared inputs, support messages, or screenshots.

Troubleshooting

Why are taken usernames missing from the dataset?

Public output intentionally omits taken and invalid_format rows. Taken results still count as conclusive successful checks and appear in the final run summary.

Why did the run fail even though the dataset contains results?

The Actor publishes available and diagnostic rows before reporting incomplete verification. Retry only usernames with unresolved diagnostic statuses.

What does budget_exhausted mean?

The username was not sent to Discord because the run's maximum charge could not admit that input position. Increase the run option maxTotalChargeUsd or submit those rows in another run.

What should I do after a rate-limit or route-capacity status?

Retry the affected usernames later. Do not merge them into an available or taken list until a conclusive response is returned.

Can public callers supply their own proxies or webhook?

No. Public callers use the Actor-managed profile. Caller-supplied advanced routing, destination, and webhook fields are discarded at the public trust boundary.

Can I check more than 5,000 usernames?

Yes, across multiple runs. Keep each public run at or below 5,000 unique usernames.

Support

When reporting a problem, include:

• The Apify run ID.
• The final summary and billing summary log lines.
• The affected usernames' non-sensitive status and error fields.

Never include passwords, API tokens, webhook URLs, or proxy URLs containing credentials.