# Stats API

Domain industry statistics as JSON: TLDs, registry operators and registrars month by month, plus nightly zone counts. Also the 2026 new gTLD round: who applied for which strings. Free, no key required.

```bash
curl https://api.namedesk.app/v1/stats/tlds/xyz
```

```json
{
  "tld": "xyz",
  "kind": "new-gtld",
  "category": "other",
  "delegated": "2014-02-19",
  "registry": { "id": 69, "name": "XYZ.COM LLC" },
  "phases": [
    { "phase": "sunrise", "start": "2014-03-20", "end": "2014-05-20" },
    { "phase": "landrush", "start": "2014-05-20", "end": "2014-06-01" },
    { "phase": "claims", "start": "2014-06-02", "end": "2014-09-02" },
    { "phase": "general_availability", "start": "2014-06-02" }
  ],
  "domains": { "period": "2026-05", "count": 8557020, "change": -121996, "change_year": 3571471 },
  "zone": { "date": "2026-10-01", "count": 10226440, "for_sale": 5413297, "parked": 917336 },
  "url": "https://namedesk.app/stats/tlds/xyz",
  "meta": {
    "as_of": "2026-10-01",
    "updated_at": "2026-10-02T02:04:55Z",
    "attribution": "Registry statistics from ICANN monthly registry reports and registry operators' own reports. Launch periods from ICANN's TLD startup pages and the Trademark Clearinghouse calendar. Zone counts from ICANN CZDS zone files."
  }
}
```

Each TLD, registry operator, registrar, group, string and application carries `url`, its page on namedesk.app. Every response carries `meta` with `attribution`, the sources to credit. A response that holds a dated figure also carries `as_of`, the newest month or date in it. `updated_at` says when the data last changed: the statistics' last update, or the 2026 round's newest change. Zone series carry no `updated_at`, and the round's responses no `as_of`.

A registry operator's `name` is its brand when no other operator uses that brand, such as GoDaddy Registry. In that case `legal_name` holds the name ICANN lists, Registry Services, LLC. Otherwise `name` is the ICANN-listed name and `legal_name` is absent. The operator's page is reachable at a URL built from either name.

## Endpoints

| Path | Returns |
|---|---|
| `/v1/stats/summary` | Totals for the newest month, by TLD kind, and the newest zone night |
| `/v1/stats/periods` | Every month the registry reports cover |
| `/v1/stats/tlds` | Every TLD with a reported figure; filter by `kind`, `category`, `registry`, `q`; sort by `domains`, `change`, `adds`, `name` |
| `/v1/stats/tlds/{tld}` | One TLD with its launch phases, newest figure and newest zone night |
| `/v1/stats/tlds/{tld}/months` | Monthly figures: domains, change, adds, renewals, deletes, transfers, restores, registrars |
| `/v1/stats/tlds/{tld}/registrars` | Each registrar's share for one month. ccTLDs have no registrar breakdown |
| `/v1/stats/tlds/{tld}/zone` | Nightly zone counts: names in the zone, entered and left, for sale, parked |
| `/v1/stats/registries` | Every registry operator running a TLD today |
| `/v1/stats/registries/{id}` | One operator, and the 2026 round applicants a public source ties to it; `/tlds` for the TLDs it runs, `/months` for its monthly total |
| `/v1/stats/registrars` | Every accredited registrar with names under management |
| `/v1/stats/registrars/{id}` | One registrar, by IANA id (`146` or `iana:146`); `/months`, `/tlds` |
| `/v1/stats/groups/{slug}` | One owner's registrars and registry operators, both when it has both: `godaddy`, `identity-digital` |
| `/v1/stats/phases` | Launch phases across TLDs; `?phase=general_availability&from=2024-01&to=2024-12` lists every TLD that opened in 2024 |

### Applications and strings

The 2026 new gTLD round, from applicants' public announcements and ICANN's published lists.

| Path | Returns |
|---|---|
| `/v1/stats/round/2026` | ICANN's calendar for the round and where the round stands on it. Counts of applications, strings applied for, applicants (companies), the legal entities they applied through, contention sets, and companies whose every claim was abandoned |
| `/v1/stats/applications` | Every application; filter by `string`, `applicant`, `status`, `category`; sort by `announced`, `string`, `contention` |
| `/v1/stats/applications/{id}` | One application, with its replacement string, IDN variants or switch |
| `/v1/stats/strings` | Strings in the round, with the AI score and verdict once a string is assessed; `role` picks which: `applied`, `backup`, `deactivated`, `abandoned` (default `applied,backup`); filter by `status`, `category`, `contested=true`; sort by `score`, `contention`, `string`, `first_seen` |
| `/v1/stats/strings/{string}` | One string, everyone on it, and its comparables from the 2012 round |
| `/v1/stats/applicants` | Every applicant with at least one application, one per company, with the legal entities it applied through and the registry operators that are the same company or are tied to it; `abandoned=true` lists instead the companies whose every claim was abandoned. `/applicants/{id}` for one applicant, abandoned or not, `/applicants/{id}/applications` for its applications |
| `/v1/stats/changes` | Every change, oldest first: a new application, a status change, a correction or a note, with the text the changelog shows for it |

`/v1/stats/applications` lists one item per ICANN application, plus each claim an applicant announced that ICANN's list does not hold. An application's replacement (backup) string and IDN variant labels are listed as applications of their own, with status `replacement` or `variant`. They name the application they belong to in `primary`, and the application names them in `replacement` and `variants`. An applicant can name the same backup string in several of its applications, so a backup string has one entry per application that names it. A backup string ICANN does not allow, because another applicant applied for the same string or named it as a backup, reads `deactivated`; it names its application in `primary`, and the application names it in `deactivated_replacement`. When an applicant switches to its replacement string in the replacement period, the old application reads `switched` and carries `switched_to`; the new one carries `switched_from`. An announced claim that is not on ICANN's list reads `ghost` (role `abandoned`).

Only an application live on ICANN's list counts toward `applications`, `applicants` and `contention`: status `confirmed`, `in-contention`, `delegated`, `sunrise` or `launched`. Nothing else counts: not a replacement, deactivated, variant, switched or abandoned entry, not a claim ICANN's list does not hold, and not an application that was withdrawn or ended another way.

Strings that are already TLDs are not part of the round, except where ICANN lists an application to add an IDN variant label to an existing TLD (`icann_types` includes `variant-only`). That application counts, under the existing TLD, as ICANN lists it, and names the new label in `variants`.

A string is in a role when at least one application puts it there, so one string can be in several. `applied`: applied for, with an application live on ICANN's list, including an IDN variant label of an application. `backup`: named as an application's replacement string. `deactivated`: named as a backup string that ICANN's list shows as deactivated. `abandoned`: announced, but not on ICANN's list.

On a string, each applicant is listed once for each `role` it has there: `applying` (an application live on ICANN's list), `replacement`, `variant`, `switched`, `deactivated`, `abandoned`, `unconfirmed` (said or reported to have applied, not on ICANN's list) or `ended` (applied, and the application ended).

An applicant is a company, listed once however many legal entities it applied through. Its `legal_entities` lists them, each with its `legal_name` as ICANN lists it and its own count; an application's `applicant` names the legal entity that filed it, and `/v1/stats/applicants/{id}` with that id returns its company. Legal entities belong to one company when their ICANN applications name the same parent or controller, or one names the other as its parent. A party that is not on ICANN's list has no `legal_name`. The round's `counts.applicants` counts each company once and `counts.legal_entities` counts the entities. An applicant's `registries` are the registry operators that are the same company or are tied to it, each backed by a public source quoted on its page, with what each runs today; a tie says who the applicant is, not who will run its new TLDs. An applicant's `website` is its company's website, and its `url` is the company's page on namedesk.app, which shows why its legal entities are one company. A company's page keeps its URL when the company is renamed. The score and verdict are our AI assessment; the [methodology](https://namedesk.app/tlds/methodology) explains them.

One string's read also carries `comps`: up to three strings from the 2012 round our AI chose as its closest parallels, closest first, each with why, how many applied for it in 2012, whether it reached the root and who won it, and its names under management in the latest month reported (from the registry statistics, with a link to its page). A string with no parallel has no `comps`.

Every parameter and field is in the [API reference](/api). A stats-only OpenAPI document is at https://namedesk.app/openapi-stats.json, for connectors and tools that take a spec URL.

## Figures

`domains.count`, or `domains` in a monthly series, is the number of registered names at the end of the month. A figure carries `estimated: true` when it comes from a registry operator's own report rather than its monthly report to ICANN. A TLD with no reported figure has no `domains` field.

Registry reports arrive about four months after the month they describe. Zone counts are from the previous night.

## Rate limits

120 requests a minute per address without a key, 600 with one. A `429` carries `Retry-After` in seconds. Responses carry `Cache-Control: max-age=3600` and an `ETag`; send `If-None-Match` to get a `304`. `/v1/stats/round/2026` is cached for less when its phase changes sooner, so it never shows a phase past its end.

## Sources and terms

Registry statistics come from the registries' monthly reports to ICANN and from registry operators' own reports. Launch periods come from ICANN's TLD startup pages and the Trademark Clearinghouse calendar. Zone counts come from ICANN CZDS zone files. 2026 round data comes from applicants' public announcements and ICANN's published lists. Credit the sources in `meta.attribution` wherever you show the numbers.

Registry and zone statistics are counts and totals only. The API never lists domain names. You may use the statistics in your own products and publications, including commercially, if you credit the sources. You may not resell them as a dataset or use them to run a competing statistics service. Zone counts depend on access the registries grant and can be withdrawn. The [Terms of Service](https://namedesk.app/terms) have the full wording.

The Stats API is in beta and free. Any change to that is announced on the [changelog](https://namedesk.app/changelog) first.