UltraFast Discord Username Checker

UltraFast Discord Username Checker bulk-checks whether Discord usernames are available or taken and returns structured, export-ready results through Apify.

Paste up to 5,000 usernames, keep the production defaults, and receive conclusive results in seconds without a Discord login, password, account token, or browser session.

What does this Actor do?

• Checks up to 5,000 unique Discord Pomelo usernames per run.
• Accepts a JSON array or pasted newline-separated text.
• Returns available usernames and any unresolved diagnostic statuses in the public dataset.
• Uses residential proxy route-capacity scheduling for fast, reliable batches.
• Charges only for successful available and taken checks.
• Supports Apify API, schedules, tasks, integrations, and dataset exports.

How do I check Discord usernames?

1. Open the Actor in Apify Console.
2. Paste one username per line into Usernames.
3. Click Start.
4. Open the dataset to view or export the results.

The public input page intentionally contains only the username list. The Actor applies its tested production configuration automatically.

Minimal input:

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

Array input:

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

Duplicate usernames are ignored. Inputs containing more than 5,000 unique usernames hard-fail before Discord checking, billing, dataset writes, or webhook delivery; split larger lists into separate runs.

What results does the Actor return?

Each dataset item contains:

Field	Description
username	Discord username that was checked.
available	true only when Discord conclusively reported the username as available.
status	Final result such as available, taken, invalid_format, or an unresolved status.
statusCode	Discord HTTP response status when available.
attempts	Number of attempts used to produce the result.
checkedAt	UTC timestamp for the result.
error	Diagnostic information for invalid, unresolved, or failed checks.

Example:

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

Availability is a point-in-time result. A username can be claimed after the check finishes.

How much does it cost?

The successful-check pay-per-event pricing charges only conclusive available and taken results:

Apify plan tier	Price per 1,000 successful checks
Free	$5.00
Bronze	$4.50
Silver	$4.00
Gold, Platinum, Diamond	$3.50

Run-time platform usage, including compute and proxy traffic, is included in that event price. Invalid input, retries, rate limits, deferred work, failed checks, and budget_exhausted rows are not successful-check events and are not charged.

This pricing became active on July 14, 2026. The Actor's Pricing tab is the source of truth for the price effective on a specific run. Post-run storage and later dataset operations can still incur standard Apify platform charges.

How does the maximum charge work?

Set maxTotalChargeUsd when starting the Actor to cap the run charge. Under successful-check pricing, the Actor calculates how many potentially billable usernames fit inside that limit before sending requests.

Inputs beyond the limit receive:

{
  "username": "samplecheck9999",
  "available": false,
  "status": "budget_exhausted",
  "attempts": 0,
  "error": "not checked because the run maximum charge was reached"
}

budget_exhausted rows are not charged and must not be interpreted as available or taken.

Which output mode is used?

Public runs always use outputMode: "available_only". The dataset contains available usernames plus unresolved and budget-exhausted diagnostic rows; conclusive taken usernames are counted in the run summary but omitted from storage. This keeps normal 5,000-name platform usage close to the measured $0.035 target without changing successful-check billing.

The Actor owner may select either available_only or all for private administrative runs. Owner recognition uses Apify's trusted run identity rather than a user-provided admin flag.

What are the production defaults?

The default profile is tuned for fast 5,000-name residential batches and is applied automatically without exposing these advanced controls on the public input page:

Setting	Default	Purpose
Memory	128 MB	Proven size for the bounded residential route-capacity preset.
concurrency	340	Keeps the measured fast launch profile while reserved routes remain idle until needed.
proxyGroup	RESIDENTIAL	Provides independent Discord request routes.
Proxy validation	enabled	Fails before scheduling when proxy credentials, access, or usage quota are unavailable.
apifyProxyRouteCount	340	Keeps enough active residential sessions for the fastest measured reliable 5,000-name run without unnecessary session overhead.
maxRequestsPerRoute	40	Provides 13,600 total safe attempts; failed or rate-limited sessions rotate while the route slot keeps its remaining budget.
maxRateLimitRetries	10	Bounds fresh-route recovery after 429s or retryable proxy failures; the run fails closed instead of retrying indefinitely.
routeCapacityMode	true	Requeues work onto fresh routes and rotates non-global rate-limited or retryably failed sessions inside the original attempt budget.
adaptiveRateLimit	false	Starts the high-throughput scheduler immediately.
requestTimeoutSeconds	10	Fails unresponsive requests quickly.
useBrowserTLS	false	Uses the lower-transfer standard Go transport.
Native HTTP/2	enabled	Compresses repeated response headers on each proxy route.
superProperties	empty	Omits an unnecessary large request header.
Standard headers	minimal	Sends only content type and a compact user-agent.
outputMode	available_only	Avoids storage charges for conclusive taken rows.

External runs receive a 180-second checking phase inside a 300-second Actor timeout, leaving time to settle billing and publish results. Owner runs can override runtime settings.

How fast is it?

Production verification completed these workloads:

Date	Workload	Result	Slowest batch
July 12, 2026	20 parallel batches × 5,000	100,000/100,000 verified	38.064 seconds
July 14, 2026	373,248 usernames across 75 batches	373,248/373,248 verified	32.156 seconds

Runtime varies with proxy availability, Discord rate limits, and Apify platform load. A verified result means Discord returned a conclusive response.

What do unresolved statuses mean?

The important final counters are:

• verified: conclusive available, taken, or invalid responses.
• unverified: checks without a conclusive response.
• deferred_rate_limit: work stopped because a shared cooldown made continuation unsafe.
• deferred_route_capacity: work left after usable safe route capacity was consumed; unused allowance on a non-global rate-limited or retryably failed Apify session is rotated to a fresh session instead of being stranded.
• retry_exhausted: a retryable request did not succeed within the configured attempts.
• budget_exhausted: the maximum run charge did not cover this input, so no check occurred.

Never treat unresolved, failed, deferred, or budget-exhausted rows as available or taken. Retry those usernames later.

Data handling

Results are stored in the run's Apify dataset. Available usernames are also sent in compact batches to the Actor owner's configured Discord webhook; other statuses are not sent. Do not submit confidential username lists.

FAQ

Does the Actor need my Discord account?

No. It does not require a Discord login, password, account token, or session cookie.

Can I check more than 5,000 usernames?

Yes, across multiple runs. Split the list into batches of at most 5,000 unique usernames.

Why was I charged for fewer usernames than I submitted?

Only available and taken outcomes are successful-check events. Invalid, unresolved, failed, and budget-exhausted rows are free under the new pricing model.

Can I use my own proxies?

Advanced inputs support external proxy routes. Proxy credentials are redacted from diagnostics, but never put reusable secrets in public tasks or shared inputs.

Why is my run slow?

Keep the production defaults. Adaptive mode intentionally launches requests at a controlled rate and is unsuitable for fast public batches.

Support

When reporting a problem, include the Apify run ID and final summary line. Never include passwords, tokens, webhook URLs, or proxy URLs containing credentials.