Can a username be analyzed without a real given name?
Yes, when you explicitly enable forceToGenderize. V2 first tries the dataset; if no gender is resolved, nickname-aware AI can interpret an alias without extracting a real given name. That is an inference, not verified identity, and the result may remain unknown. Without this option, ordinary AI inference requires a usable real given name.
This guide focuses on processing a dataset of handles with row-level policies and recoverable results. Use the username tool for a single interactive lookup, then use the batch workflow below when you are ready to integrate.
Try the V2 API
Analyze a username
Submit one value and inspect the complete response, including unknown results and credit usage.
Real response captured on 1 October 2026 below. Select Analyze username to run a live lookup.
| Name | Daniel |
|---|---|
| Gender | Male |
| Confidence | 98% |
| Source | AI model |
| Credits used | 2 |
{
"data": {
"input": {
"type": "username",
"value": "daniel92",
"country": null
},
"name": "daniel",
"gender": "male",
"country": null,
"confidence": 0.98,
"confidence_kind": "model_reported",
"sample_count": null,
"source": "ai",
"result_status": "identified",
"reason": null,
"country_source": null,
"match": {
"name": null,
"method": "model_inference",
"scope": null,
"country": null
}
},
"meta": {
"request_id": "a9225ac2-f6e0-47b2-b5bf-2dcd4e2eff1b",
"duration_ms": 385,
"access": {
"mode": "api_key",
"reason": null
},
"usage": {
"charged_credits": 2,
"remaining_credits": 49999,
"billing_status": "confirmed",
"resets_at": null,
"limit": null,
"period_seconds": null
}
}
}This real response was captured on 1 October 2026; only the account balance is replaced. Live values may differ. A prediction is not verified identity.
Preserve the handle and choose the input type
Keep your source-system record ID, the original handle and any person-supplied name in separate fields. Send the handle as type: username, not as a full profile URL. Use type: email for email addresses and type: name when the source is an actual name. The API does not fetch a social profile or verify account ownership.
Dataset processing removes a leading @, normalizes the text and derives candidates from delimiters and digits. Ordinary lookup may add bounded prefix and suffix candidates for a concatenated handle; forceToGenderize keeps token matching but omits those extra substring candidates. Multiple matches are resolved by the largest stored total, so inspect match.name and match.method instead of assuming that the handle contains a verified first name.
| Example input | What your application should preserve |
|---|---|
@alice_smith | Keep the original handle and inspect the selected candidate; the API may match a component. |
prenses | Keep the alias even if nickname inference returns a gender with name: null. It has not established a real name. |
user47291 | Keep unknown as a valid outcome. Digits or an opaque identifier do not establish a person's gender. |
Choose a policy for each row before submission
Batch items default to AI off, while single requests default to ordinary fallback. Choose explicitly when the distinction matters. forceToGenderize is optional for username, name and email inputs; it accepts an omitted ai_mode or fallback, but conflicts with off and always.
Successful unknown outcomes are also charged. A positive starting credit balance is sufficient to begin an operation, and the final debit can take it below zero. Use meta.usage and each item's charged_credits to reconcile the completed operation, rather than treating a maximum cost estimate as its final charge.
| Policy | Processing | Successful item cost |
|---|---|---|
| options.ai_mode: off | Dataset only; unresolved inputs remain unknown. | 1 credit |
| options.ai_mode: fallback | Dataset first, then ordinary AI if no gender is resolved. | 1 credit total, including AI |
| options.ai_mode: always | AI directly, without a dataset lookup. | 2 credits |
| forceToGenderize: true | Dataset first, then nickname-aware AI when unresolved; a real name is not required. | 1 credit for a resolved dataset result; 2 total if AI is used |
Submit a batch with stable row identifiers
The request below demonstrates three choices: a dataset-only handle, ordinary AI fallback and nickname-aware fallback. These are example inputs, not expected predictions. Use your existing Bearer API key; keep GENDERAPI_API_KEY on your server. Give every item an id that is unique within this batch.
Send at most 50 items per API-key batch or 10 for the shared IP trial. For a longer file or database export, maintain a job ID and the source row independently of each batch's zero-based index. Do not use a display name as the identifier, because different records can share it.
Choose your language. Set up your API key, then run the example on your server.
Every prediction request is a new billable operation, including retries. These examples do not automatically retry. Check billing status before sending another request.
Before you run: access and error handling
Run these examples on your server. Set GENDERAPI_API_KEY in the process environment to your existing API key. Confirm meta.access.mode is api_key: an unrecognized key can fall back to the IP trial.
HTTP 4xx and 5xx JSON responses preserve the error body and return a nonzero exit status. Check code, action and meta.usage.billing_status before retrying. For HTTP 200 batch responses, also inspect each item's data or error.
Error and retry guide →cURL 7.76+ in a POSIX shell. Run in your terminal. Runtime documentation
Node.js 22+; built-in fetch. Save as example.mjs and run node example.mjs. Runtime documentation
Python 3.10+; standard library. Save as example.py and run python3 example.py. Runtime documentation
PHP 8+ with the cURL extension. Save as example.php and run php example.php. Runtime documentation
Java 17+; standard HTTP client. Save as GenderApiExample.java and run java GenderApiExample.java. Runtime documentation
.NET 8+ console application. Use as Program.cs in a console project, then run dotnet run. Runtime documentation
Go 1.22+; standard library. Save as main.go and run go run main.go. Runtime documentation
Reconcile every row, including unknowns and errors
Read the response as a set of item outcomes. HTTP 200 does not guarantee that all items succeeded, and a successful item does not guarantee an identified gender. Save meta.request_id and map each item back to the original record using its id or index.
When billing is confirmed, retry only failed items whose errors warrant another attempt. Resubmitting successful items, including unknowns, starts new billable operations. meta.summary.succeeded includes both identified and unknown items, so retain those categories separately in your own job report.
| Item outcome | How to store or handle it |
|---|---|
| data.result_status: identified | Store gender together with source, confidence_kind, confidence and match. An identified inference remains an estimate. |
| data.name: null with a gender | Valid in nickname mode. Preserve the alias; do not manufacture a real name from the prediction. |
| data.result_status: unknown | Keep JSON null and reason. not_found, no_name_candidate, ambiguous and insufficient_evidence describe different unresolved outcomes; none is an automatic retry instruction. |
| error present | Keep the error code. Check billing and the error's retry guidance before resubmitting that failed item. |
| meta.usage.billing_status: unconfirmed or response lost | Pause and reconcile before retrying; a missing response does not prove that credits were not charged. |
Evaluate a policy before filling a dataset
Use representative, independently labeled examples for the languages, input styles and modes your application will process. Evaluate dataset observed_frequency and AI model_reported scores separately. There is no universal confidence cutoff that proves a username prediction correct, and stored sample_count is not a product-accuracy measurement.
Keep an unknown or review path, retain information supplied by the person, and record how many inputs your chosen policy answers as well as how often those answered predictions are correct. If AI is invoked, the submitted username and country context go to the configured inference service; the API does not return the underlying model revision in the prediction response.
Frequently asked questions
Does a username lookup visit the social-media profile?
No. V2 analyzes the submitted value and optional country context. It does not fetch a social profile or verify that the handle belongs to a particular person.
Can nickname inference return a gender when name is null?
Yes. forceToGenderize allows nickname-aware inference without a real given name. A non-null gender with name: null can therefore be an identified result; it is still an estimate and does not verify identity.
Should I retry every unknown item in a batch?
No. Unknown items are completed, billable outcomes. Retry decisions apply to operational errors after checking billing and the error guidance. Resending a successful item, including an unknown, is a new billable operation.