# Discord Username Availability Checker (`khadinakbar/discord-username-checker`) Actor

Bulk-check Discord username availability via the official signup API. Tokenless, no login, no captcha. Returns available / taken / invalid per handle.

- **URL**: https://apify.com/khadinakbar/discord-username-checker.md
- **Developed by:** [Khadin Akbar](https://apify.com/khadinakbar) (community)
- **Categories:** Social media, Automation, Other
- **Stats:** 4 total users, 0 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $8.00 / 1,000 username checkeds

This Actor is paid per event and usage. You are charged both the fixed price for specific events and for Apify platform usage.

Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Discord Username Availability Checker

This actor tells you whether a batch of Discord usernames is available, taken, or invalid, so you can decide which handle to claim or skip — without logging in, captchas, or any user token. Call it with a list of candidate handles and it returns a clean status row per handle straight from Discord's own signup availability API, with an `available` flag you can feed directly into a registration or naming decision.

It is designed for anyone who needs to verify Discord handle availability at scale: community organizers reserving a giveaway name, brands confirming a handle that matches across platforms, content creators keeping a consistent name, or developers who want a tokenless availability check for a tool or workflow.

### Why it works as a focused standalone workflow

This actor is designed as a focused standalone workflow: you run one batch, read the dataset rows, and act on them. It produces a complete answer in a single run and needs no other tooling, chaining, or external service to be useful.

### Output: per-handle results

For each input handle, the actor writes one dataset row with a stable status. The `available` boolean is the key decision field; `status` is the human-readable classification.

| Field | Meaning |
|-------|---------|
| `status` | One of `available`, `taken`, `invalid`, `rateLimited`, or `unknown`. |
| `available` | `true` when the handle is free to claim. |
| `taken` | `true` when the handle is already in use. |
| `reason` | Context for `invalid` results (for example, length or allowed characters). |
| `checkedAt` | ISO timestamp of when the check ran. |

```json
{
  "username": "novanex",
  "requestedUsername": "Novanex",
  "status": "available",
  "available": true,
  "taken": false,
  "checkedAt": "2026-08-17T00:00:00.000Z"
}
```

### Quick start: input

Provide one or more username candidates. Only `usernames` is required.

```json
{
  "usernames": ["novanex", "coolname_23"],
  "maxConcurrency": 8,
  "proxyCountry": ""
}
```

Handles are case-insensitive and are de-duplicated, so casing does not cost you extra checks.

### Pricing (Pay per event)

This actor uses Pay per event (PPE) with platform usage passed through to the end user. There are two event types:

- **Actor start** — charged once per run to cover initialization and proxy wiring.
- **Username checked** — charged only for handles that received a definitive answer (`available`, `taken`, or `invalid`). Handles that could not be checked are not billed.

Cost scales 1:1 with definitive results, so a batch of 25 handles whose every check succeeds is 25 checked events plus the single start. The live **Pricing tab** on this actor is the current source of truth for exact event prices.

### Run one from the API

```bash
curl -X POST \
  "https://api.apify.com/v2/acts/khadinakbar~discord-username-checker/runs?token=YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "usernames": ["novanex", "coolname_23"] }'
```

Then read the dataset for the run to collect the per-handle status rows.

### Workflow: from candidate list to claim

Start with your shortlist of candidate handles. Pass them all in one `usernames` array, and the actor checks them concurrently. Then compare the `available: true` rows to pick the handle you want, and claim it in Discord's signup flow. Because results drop into the dataset as structured rows, you can export them, schedule a periodic re-check of your shortlist, or feed the available handles into your own registration script.

### Using this from an AI agent or MCP tool

An agent can treat this as a tokenless availability probe. Pass the candidate handles as input, then read the run's dataset for per-handle `status` and `available`.

> Invoke the actor with a shortlist, read back the dataset status rows, and use each row's `available` flag plus cost context to decide which handle to claim. A run that never reaches Discord returns only `rateLimited` or `unknown` statuses and leaves the claim decision open. The dataset is the unit you read back, cost is driven by definitive results, and pagination is not needed because one run covers the full batch you submit.

### Best-fit guidance and scope

This actor is the right fit when you want a tokenless verdict on whether Discord handles are free, at any batch size up to 500. For best results, provide a focused shortlist you actually plan to use, keep concurrency at the default unless Discord throttling appears, and schedule repeat checks if you are monitoring a name that may become available. If a handle comes back `rateLimited`, wait and run it again rather than treating it as taken — throttled checks are not billed to you.

To validate claims before spending, confirm you are authorized to check the target handles and that you intend to use the result within Discord's site terms.

### Builder's note

I built this because checking Discord username availability normally means opening the registration form repeatedly, one handle at a time, with no way to compare a batch. I found the unauthenticated signup endpoint returns a clean taken/available verdict with no captcha, so the whole actor stays tokenless — no login, no stored credentials, nothing to break when Discord rotates authentication. In my testing, rotating a fresh residential session per request is what keeps bulk checks from tripping the per-IP throttle, which is why the actor handles retries and low-concurrency runs gracefully. My goal was a drop-in answer for the most common question — "is this name free?" — resolved in one run with per-handle rows.

### Responsible use

Use this actor only for handle availability checks you are authorized to perform and that comply with Discord's site terms and any applicable laws in your region. It performs read-only availability lookups and takes no registration action on the names it checks.

# Actor input Schema

## `usernames` (type: `array`):

List of Discord usernames (unique handles, no discriminator) to check for availability. Up to 500 per run. Checks are case-insensitive and run against the official Discord signup API — no account, token, or login is required. Enter one handle per line (e.g. \['novanex','coolname\_23']).

## `maxConcurrency` (type: `integer`):

How many availability checks may run in parallel. Discord rate-limits the availability endpoint per IP, so keep this modest (5-15). Each check typically uses a rotating residential IP to avoid 429 rate-limit blocks. Raise it cautiously on very large lists.

## `proxyCountry` (type: `string`):

Optional two-letter country code for the residential proxy region (e.g. 'US', 'DE'). Leave empty to let Apify auto-select. Only applies when the built-in Apify proxy is enabled (the default).

## Actor input object example

```json
{
  "usernames": [
    "novanex",
    "coolname_23"
  ],
  "maxConcurrency": 8,
  "proxyCountry": ""
}
```

# Actor output Schema

## `results` (type: `string`):

All Discord username check records as JSON (dataset).

## `runSummary` (type: `string`):

Run-level summary record written at the end of each run.

## `output` (type: `string`):

Terminal outcome summary written at the end of each run.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "usernames": [
        "novanex",
        "coolname_23"
    ],
    "maxConcurrency": 8
};

// Run the Actor and wait for it to finish
const run = await client.actor("khadinakbar/discord-username-checker").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "usernames": [
        "novanex",
        "coolname_23",
    ],
    "maxConcurrency": 8,
}

# Run the Actor and wait for it to finish
run = client.actor("khadinakbar/discord-username-checker").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "usernames": [
    "novanex",
    "coolname_23"
  ],
  "maxConcurrency": 8
}' |
apify call khadinakbar/discord-username-checker --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,khadinakbar/discord-username-checker"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/M073YEfHwDBf964uR/builds/D6FBD2gy59pDRfmKf/openapi.json