# Username Availability (`scrapers-hub/username-availability`) Actor

Username Availability checks handles across many platforms in parallel and returns per-platform availability, profile URL and a run summary of checks, taken names and errors. 🔍 For brand protection, naming research and OSINT.

- **URL**: https://apify.com/scrapers-hub/username-availability.md
- **Developed by:** [Scrapers Hub](https://apify.com/scrapers-hub) (community)
- **Categories:**
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $1.99 / 1,000 results

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/actors/running/actors-in-store.md#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

## 🔍 Username Availability Checker – Bulk Handle Search Across Social Platforms

The **Username Availability** checker tests whether a username is free or already taken across dozens of social, developer, gaming and creator platforms in a single run. Type one handle — or a comma-separated list of them — and get back a row per platform showing the profile URL and a simple `available` boolean, plus a summary record telling you how many platforms were checked and how the results broke down.

This username availability checker exists because claiming a consistent handle is a genuinely tedious job. A new brand, product or creator identity needs the same name on GitHub, Instagram, TikTok, X, YouTube, Reddit, Twitch and a long tail of smaller sites, and checking each one by hand means thirty-odd browser tabs and no record of what you found. The actor does the same work in one run and leaves you with a dataset you can sort, filter and keep.

***

### 📊 What Data Can You Extract with This Username Availability Checker?

The actor produces two record shapes: one per platform check, and one summary per username. The fields group as follows:

| Category | Fields | What it tells you |
|---|---|---|
| 👤 Handle | `username` | The username that was checked, echoed onto every result row |
| 🌐 Platform | `platform` | The platform name the check ran against, e.g. `GitHub`, `Instagram`, `Twitch` |
| 🔗 Profile URL | `url` | The exact profile URL that was tested, ready to open or claim |
| ✅ Verdict | `available` | `true` when the handle appears free, `false` when it appears taken, and null when the check was inconclusive |
| ⚠️ Failure detail | `error` | The reason a check could not produce a verdict — an unexpected status code or a network error |
| 📈 Run summary | `_summary`, `usernamesChecked`, `platformsChecked`, `totalChecks`, `taken`, `errors` | A per-username summary record giving totals for the run |

The field doing the real work is `url`. Because every row carries the exact profile URL that was tested, an available result is immediately actionable — you click straight through to the registration page for that handle rather than navigating the platform to find it. For an inconclusive result, the same URL lets you verify manually in seconds.

***

### 🌟 Key Features of the Username Availability Checker

| Feature | Description |
|---|---|
| 🌐 Wide platform coverage | Checks a fixed list of more than thirty platforms spanning social, developer, music, gaming, publishing and creator sites |
| 👥 Multiple usernames per run | The `usernames` field accepts a comma-separated list, and each handle gets its own set of checks and its own summary record |
| ✅ Simple boolean verdict | `available` is a plain boolean, so filtering a spreadsheet to the free handles is a single click |
| 🔗 Direct profile URLs | Every row includes the exact URL tested, so a free handle is one click from being claimed |
| 📊 Per-username summary | A `_summary` record reports `usernamesChecked`, `platformsChecked`, `totalChecks`, `taken` and `errors` for each handle |
| ⚠️ Transparent inconclusive results | When a platform returns something other than a clear found/not-found response, the reason lands in `error` rather than being silently reported as a verdict |
| 🕵️ Browser-grade request fingerprint | Requests are made with `curl_cffi` browser impersonation, which improves how many platforms respond normally |
| ⏱️ Adjustable request pacing | `delayBetweenRequests` controls the gap between checks, letting you trade run speed against politeness |
| 🪶 No browser, no proxy | Direct HTTP requests with no headless browser and no proxy layer, so runs are light and start instantly |

***

### 🚀 Why Choose This Username Availability Checker?

**One run replaces thirty browser tabs.** Checking a handle manually across the platforms that matter to a brand launch is an hour of clicking. This actor turns it into a single input field and a dataset, and — unlike the manual approach — it leaves you with a record you can revisit.

**Availability plus the URL to act on.** A verdict without a link is only half useful. Because `url` is on every row, an available handle can be claimed immediately and a questionable one can be verified by eye without hunting through a platform's search.

**Inconclusive results are labelled, not guessed.** Some platforms respond to unauthenticated profile requests in ways that do not map cleanly to "taken" or "free". Rather than forcing a verdict, the actor sets `available` to null and records why in `error`, so you know exactly which handles need a manual look.

**Batch handle testing for naming decisions.** Because `usernames` accepts a comma-separated list, you can test an entire shortlist of candidate brand names in one run and pick the one with the cleanest availability profile across the platforms you care about.

***

### 📥 Input

The username availability checker takes one required field plus three optional controls.

```json
{
  "usernames": "coolbrand2026",
  "platforms": "",
  "concurrency": 5,
  "delayBetweenRequests": 0.5
}
```

#### 🔧 Username Availability Checker Input Fields

| Field | Type | Required | Default | Description |
|---|---|---|---|---|
| `usernames` | string | ✅ Yes | `"coolbrand2026"` | A single username to search, or a comma-separated list |
| `platforms` | string | ❌ No | `""` | Comma-separated list of platforms to check (leave empty for all) |
| `concurrency` | integer | ❌ No | `5` | Number of concurrent requests |
| `delayBetweenRequests` | number | ❌ No | `0.5` | Delay in seconds between requests |

#### 💡 Input Examples

**Single handle, all platforms:**

```json
{
  "usernames": "coolbrand2026"
}
```

**Brand-name shortlist** — test several candidates in one run:

```json
{
  "usernames": "northpeaklabs, northpeak, north-peak-labs",
  "delayBetweenRequests": 0.5
}
```

**Slower, gentler pacing** for a long list of handles:

```json
{
  "usernames": "brandone, brandtwo, brandthree, brandfour",
  "delayBetweenRequests": 1.5
}
```

***

### 📤 Output

The actor writes two kinds of record. First, one result per platform checked. This is a real record from an actual run of the username availability checker:

```json
{
  "username": "coolbrand2026",
  "platform": "GitHub",
  "url": "https://github.com/coolbrand2026",
  "available": true
}
```

Then, after each username's checks complete, a summary record:

```json
{
  "_summary": true,
  "usernamesChecked": 1,
  "platformsChecked": 36,
  "totalChecks": 36,
  "taken": 21,
  "errors": 2
}
```

#### 🧾 Username Availability Output Fields — Platform Results

| Field | Type | Description |
|---|---|---|
| `username` | string | null | The username or handle that was checked |
| `platform` | string | null | Platform the result came from |
| `url` | string | null | Canonical profile URL that was tested |
| `available` | boolean | null | Whether the handle appears available on that platform |
| `error` | string | null | Error message, if the check could not produce a verdict |

#### 🧾 Username Availability Output Fields — Run Summary

| Field | Type | Description |
|---|---|---|
| `_summary` | boolean | null | Marks the record as a summary rather than a platform result |
| `usernamesChecked` | integer | null | Number of usernames covered by this summary |
| `platformsChecked` | integer | null | Number of platforms checked |
| `totalChecks` | integer | null | Total number of checks performed |
| `taken` | integer | null | Number of platforms where the handle was found to be taken |
| `errors` | integer | null | Number of checks that could not produce a verdict |

Note that `error` only appears on rows where a check actually failed, so many platform records will have four keys rather than five. Filter on the presence of `error`, or on `available` being null, to isolate the checks that need manual follow-up.

***

### 💻 How to Use the Username Availability Checker (Step by Step)

#### Step 1: Decide Which Handles You Want to Test

Before running anything, write down your candidate handles. For a brand launch this usually means the exact brand name plus two or three fallbacks — a hyphenated variant, a suffixed variant such as `hq` or `app`, and a shortened form. Testing the shortlist together is far more informative than testing them one at a time, because what you actually want to know is which candidate is cleanest overall.

#### Step 2: Enter Them in the `usernames` Field

The field takes a single handle or a comma-separated list. Whitespace around the commas is handled, so `brandone, brandtwo, brandthree` works as written. Each handle in the list is processed independently and produces its own set of platform results plus its own summary record.

#### Step 3: Set the Request Pacing

`delayBetweenRequests` defaults to 0.5 seconds. That is a reasonable balance for a single username. If you are testing a long list of candidates and want to be gentler on the platforms being queried, raise it — the trade-off is simply a longer run. There is also a `concurrency` field for the number of concurrent requests.

#### Step 4: Run the Username Availability Check

Press **Start**. The actor works through the platform list for each username in turn, requesting the profile URL and interpreting the response. Requests are made with browser impersonation, which improves how many platforms respond normally to an unauthenticated request. The log reports each username as it begins and finishes.

#### Step 5: Filter to the Available Handles

Open the **Dataset** tab and filter to `available: true`. This is your list of platforms where the handle is free right now. If you are comparing candidates, group by `username` first and count the available results per candidate — that count is the single most useful number for a naming decision.

#### Step 6: Review the Inconclusive Checks

Filter to rows where `available` is null or `error` is populated. These are the platforms whose response could not be mapped to a clear verdict. Open the `url` from each of these rows in a browser and check by eye. There are usually only a handful, and resolving them takes a couple of minutes.

#### Step 7: Claim the Handles You Need, Then Re-check Later

Availability is perishable. Once you have decided on a name, register the handle on your priority platforms immediately, even on services you do not plan to use yet — defensive registration is far cheaper than negotiating for a handle later. Re-run the check periodically on the platforms you skipped, because handles are released as accounts are deleted.

***

### 🔌 API Access & Integrations

Run the username availability checker from your own application. The synchronous endpoint starts a run and returns the dataset in one call:

```bash
curl -X POST "https://api.apify.com/v2/acts/scrapers-hub~username-availability/run-sync-get-dataset-items?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "usernames": "coolbrand2026",
    "delayBetweenRequests": 0.5
  }'
```

With the official Python client:

```python
from apify_client import ApifyClient

client = ApifyClient("YOUR_TOKEN")

run_input = {
    "usernames": "northpeaklabs, northpeak",
    "delayBetweenRequests": 0.5,
}

run = client.actor("scrapers-hub/username-availability").call(run_input=run_input)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    if item.get("_summary"):
        continue
    if item.get("available"):
        print("FREE:", item["username"], item["platform"], item["url"])
```

The actor connects to Zapier, Make, Google Sheets, Slack and generic webhooks through Apify's standard integrations, so a scheduled availability check can post straight into a channel when a watched handle frees up.

***

### 💡 Best Use Cases for Username Availability Data

#### 🏷️ Brand Name Validation

Before committing to a name, run it through the checker and count how many platforms return `available: true`. A name that is free on three platforms out of thirty is a name that will cause friction for years. This is one of the cheapest de-risking steps available at the naming stage.

#### 🚀 Product and Startup Launch Prep

Launch checklists routinely miss handle registration until after the announcement, by which point squatters have moved. Running the check early gives you a `url` list you can work through in an afternoon and secure your identity on every platform that matters.

#### 🎥 Creator Identity Consistency

Creators need the same handle across YouTube, TikTok, Instagram, Twitch and X so an audience can find them anywhere. Filtering the dataset by `platform` and `available` shows immediately whether a chosen name can be consistent, or whether a variant is unavoidable.

#### 🛡️ Defensive Handle Registration

Identify the platforms where your brand handle is still free and claim it even where you have no immediate plans. `platform` and `url` together give you a ready-made worklist, and defensive registration is dramatically cheaper than recovering a handle from someone else later.

#### 👨‍💻 Developer and Open Source Presence

Developer platforms are covered alongside social ones, so you can confirm that a project or organisation name is free on the code-hosting and developer-identity services before you publish a repository under a name you may have to change.

#### 🔁 Monitoring Handles That Are Currently Taken

Handles are released when accounts are deleted. Schedule a recurring check on the specific handles you want and watch for `available` flipping from `false` to `true`. Wired to a Slack integration, this gives you an alert the moment a name you want becomes claimable.

#### 📋 Naming Shortlist Comparison

Put your entire candidate list into `usernames` in one run and compare the summary records. The `taken` and `errors` counts per username give you a direct, quantitative comparison across candidates rather than a vague impression built from scattered manual checks.

***

### ⚙️ Tips for Better Username Availability Checking

- **Test variants alongside the exact name.** Include hyphenated, shortened and suffixed forms in the same run. If the exact name is gone everywhere, you want the fallback data in the same dataset rather than in a second run.
- **Always verify before you commit.** A `true` verdict means the profile URL did not resolve to an existing account. Platform-specific reserved words, minimum length rules and trademark policies can still block registration, so confirm at the signup form.
- **Raise `delayBetweenRequests` for long lists.** The 0.5-second default is fine for one handle across the platform list. For a large candidate list, a longer delay is gentler on the platforms being queried and reduces inconclusive results.
- **Treat null `available` as "check manually", not as "taken".** Null means the response could not be interpreted, which is a different thing from the handle being unavailable. The `url` field makes manual verification quick.
- **Filter out the summary rows before analysis.** Records with `_summary: true` have a different shape from platform results. Exclude them when building a spreadsheet of availability, then read them separately for the totals.
- **Re-run periodically for handles you are watching.** Availability changes. A scheduled monthly run on a small watch list costs almost nothing and catches releases you would otherwise miss.

***

### 🛠️ Troubleshooting

**Some platforms returned an error instead of a verdict.**
The platform responded with something the checker could not map to found or not-found — an unexpected status code, a rate-limit response, or a network failure. The reason is recorded in `error`. Open the `url` and confirm by eye; a handful of manual checks per run is normal.

**A handle showed as available but registration was rejected.**
Availability here means no public profile exists at that URL. Platforms additionally enforce reserved words, minimum and maximum lengths, character restrictions and trademark policies at signup. The check is a strong first filter, not a guarantee.

**A platform reports every username as taken.**
Some platforms return a valid page for any handle, including ones that do not exist, which reads as taken. Cross-check one obviously nonsense handle on that platform: if it also reports taken, the platform's response cannot be interpreted reliably and you should verify manually.

**Increasing `delayBetweenRequests` made the run much slower.**
That is the expected trade-off. The delay is applied between each individual check, and with a long platform list and multiple usernames the total adds up quickly. Keep the delay modest unless you are seeing rate-limit errors.

**My comma-separated list produced results for only one username.**
Check the formatting. Separate handles with commas — `one, two, three`. A list separated by spaces or newlines will be read as a single handle.

***

### ❓ Frequently Asked Questions About Username Availability Checking

**What does the Username Availability checker do?**
It requests the profile URL for your handle on each platform in its list and reports whether an account exists there, returning the platform name, the URL tested and an `available` boolean for each check.

**How many platforms does it check?**
A fixed list of more than thirty, covering social networks, developer platforms, music and audio services, gaming sites, publishing platforms and creator tools. The exact count for a run is reported in the summary record's `platformsChecked` field.

**Can I check more than one username at a time?**
Yes. The `usernames` field accepts a comma-separated list, and each handle produces its own platform results and its own summary record.

**How does the username availability checker decide if a handle is free?**
It interprets the HTTP response for the profile URL. A not-found response indicates the handle is available; a found response, including a redirect to an existing profile, indicates it is taken. Anything else is reported as inconclusive with a reason in `error`.

**Does `available: true` guarantee I can register the handle?**
No. It means no public profile exists at that URL. Platforms also apply reserved-word lists, length and character rules, and trademark policies at signup, so always confirm at the registration form.

**What does a null `available` value mean?**
The check could not produce a reliable verdict, usually because the platform returned an unexpected response. Treat it as "verify manually" and use the `url` field to check by eye.

**What is the `_summary` record?**
A per-username roll-up written after that handle's checks finish, reporting `usernamesChecked`, `platformsChecked`, `totalChecks`, `taken` and `errors`.

**Do I need an account on any of these platforms?**
No. The checker makes unauthenticated public requests only. No logins, cookies or tokens are involved.

**Do I need to configure a proxy?**
No. The actor makes direct requests without a proxy layer.

**What does `delayBetweenRequests` control?**
The pause in seconds between individual checks. The default is 0.5. Raising it slows the run but is gentler on the platforms being queried.

**Can I export the username availability results?**
Yes. Apify datasets export as JSON, CSV, Excel, XML, RSS and HTML, and are readable through the Apify API and official clients.

**Can I monitor a taken handle and be alerted when it frees up?**
Yes. Schedule a recurring run on that handle and connect a Slack or webhook integration to notify you when `available` changes to `true`.

**Why do some rows have four fields and others five?**
The `error` key is only added when a check fails. Successful checks return `username`, `platform`, `url` and `available`.

**Is checking username availability legal?**
Requesting a public profile URL is ordinary web traffic. Registering a handle that infringes someone else's trademark is a separate matter and is your responsibility — see the disclaimer below.

**How current are the results?**
They reflect the moment of the check. Handles are registered and released continuously, so re-run before acting on a result that is more than a few days old.

***

### 🆘 Support & Feedback

If the username availability checker misreports a platform, or you would like a platform added to the list, open a ticket on the **Issues** tab of this actor. Include the handle, the platform and the run ID so the behaviour can be reproduced.

Need a custom build — a different platform list, domain availability checking alongside handles, or continuous monitoring with alerting? Email **scraperhubapi@gmail.com** and describe what you need.

If this username availability checker saves you an afternoon of manual tab-clicking, please leave a review on the actor page. Ratings help other founders, marketers and creators find the tool and shape what gets added next.

***

### ⚖️ Disclaimer

The Username Availability checker makes standard, unauthenticated public HTTP requests to profile URLs and records whether a profile exists. It does not log into any platform, does not use cookies or access tokens, does not attempt to bypass authentication, and does not collect profile content, personal data or account details of any kind — only whether a URL resolves.

Results reflect the response returned at the moment of the check and are not a guarantee of registrability. Platforms enforce reserved-word lists, length and character rules, verification requirements and trademark policies at signup, and any of these may prevent registration of a handle this tool reports as available. Availability also changes constantly as accounts are created and deleted.

You are responsible for how you use these results. Registering a username that infringes a third party's trademark, impersonates a person or organisation, or is intended for resale may breach the platform's terms of service and applicable law. Check trademark registers and each platform's naming and impersonation policies before claiming a handle commercially.

Although this username availability checker collects only handle strings, platform names and URLs, a username can itself identify an individual. Where that is the case, GDPR, UK GDPR, CCPA and equivalent privacy laws may apply to the resulting dataset and you should handle it accordingly.

If you believe data collected by this actor relates to you and should be removed, contact **scraperhubapi@gmail.com** with the details and the request will be actioned.

# Actor input Schema

## `usernames` (type: `string`):

A single username to search, or comma-separated list.

## `platforms` (type: `string`):

Comma-separated list of platforms to check (leave empty for all)

## `concurrency` (type: `integer`):

Number of concurrent requests

## `delayBetweenRequests` (type: `number`):

Delay in seconds between requests

## Actor input object example

```json
{
  "usernames": "coolbrand2026",
  "platforms": "",
  "concurrency": 5,
  "delayBetweenRequests": 0.5
}
```

# Actor output Schema

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

Records scraped by Username Availability, stored in the run's default dataset.

# 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 = {};

// Run the Actor and wait for it to finish
const run = await client.actor("scrapers-hub/username-availability").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 = {}

# Run the Actor and wait for it to finish
run = client.actor("scrapers-hub/username-availability").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 '{}' |
apify call scrapers-hub/username-availability --silent --output-dataset

```

## MCP server setup

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

```

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/tavCG2e4zbNMXxiaZ/builds/NPfk8Xi8b6LAUDUiV/openapi.json