Domains

Returns pricing for every zone you can sell across your connected registrar accounts. Each row includes the price and zone metadata — classification, tier, abuse posture, and verification requirements.

Modes

• mode=best (default) — one row per TLD with the cheapest register-1Y price across your providers.
• mode=all — one row per (TLD × provider account), for comparing prices across accounts.

Filtering

• tlds — comma-separated list, max 50. Example: tlds=com,net,io.
• registrars — comma-separated provider types. Example: registrars=SPACESHIP,DYNADOT.

Zone metadata fields

Every price row includes these classification fields from the TLD registry:

tldType — zone classification:

tldTier — zone level:

abuseResistant — true if the zone is known for tolerating abuse (slow or no takedowns). abuseNote gives a human-readable reason.

Disclaimer: abuse tolerance data is approximate and may be outdated. Registries change their enforcement posture over time — a TLD marked tolerant today may tighten enforcement tomorrow (and vice versa). This field is based on community reports and public research, not official registry statements. Do not treat it as legal advice or a guarantee. Always verify the current abuse policy of a specific registry before relying on it for operational decisions.

Categories:

Note on cheap new gTLDs (.xyz, .top, .icu, .cyou, .cfd, .lol, etc.): these are not abuse-resistant — the opposite. They are heavily abused due to low prices, but Spamhaus and other blocklists detect them immediately on first complaint. Domains on these zones get blocked faster than on any other TLD. They are not flagged as abuseResistant in this API.

Sources used for abuse tolerance classification:

verificationType — what kind of registration verification the registry requires:

verificationStandard is a shortcut boolean: true when verificationType === "standard", false otherwise. Use it to quickly filter zones your clients can register without extra paperwork.

Examples

Code
# Full catalog, cheapest per zone
curl -H "Authorization: Bearer bk_..." \
  https://api.most.ac/v1/tlds

# Only .com, .net, .io
curl -H "Authorization: Bearer bk_..." \
  "https://api.most.ac/v1/tlds?tlds=com,net,io"

# Per-provider breakdown for Spaceship
curl -H "Authorization: Bearer bk_..." \
  "https://api.most.ac/v1/tlds?mode=all&registrars=SPACESHIP"

# Only country-code TLDs
curl -H "Authorization: Bearer bk_..." \
  "https://api.most.ac/v1/tlds?type=country"

# Only second-level zones (.co.uk, .com.au, etc.)
curl -H "Authorization: Bearer bk_..." \
  "https://api.most.ac/v1/tlds?tier=2"

# Only abuse-resistant zones
curl -H "Authorization: Bearer bk_..." \
  "https://api.most.ac/v1/tlds?abuse=true"

# Only zones with standard verification (no extra paperwork)
curl -H "Authorization: Bearer bk_..." \
  "https://api.most.ac/v1/tlds?verification=standard"

# Combine: abuse-resistant country TLDs on Dynadot
curl -H "Authorization: Bearer bk_..." \
  "https://api.most.ac/v1/tlds?type=country&abuse=true&registrars=DYNADOT"

# All CNNIC zones requiring audit
curl -H "Authorization: Bearer bk_..." \
  "https://api.most.ac/v1/tlds?verification=cnnic"

Returns a paginated list of domains owned by clients under your account.

Check availability and pricing for up to 35 domains at once against a specific registrar.

Registrar-specific limits

• Spaceship applies its own rolling cap of 30 search requests per 30 seconds per reseller account, and it's enforced server-side by Spaceship — not by Most. The limit is scoped to search/availability only; registrations, NS updates and other write operations are not counted. If you need high search throughput on Spaceship you have to split load across multiple accounts. See the registrar peculiarities page for the full list of Spaceship quirks.

Transfer ownership of a domain to a different client. The domain's contacts (registrant/admin/tech/billing) are automatically remapped to the target client's contacts by type.

The target client must have at least a REGISTRANT contact before a domain can be assigned. Missing admin/tech/billing contacts fall back to the registrant.

Renew up to 25 domains at once. Creates an async task — prices are looked up server-side from the registrar catalogue, so you can't spoof them.

Returns a taskId — poll /v1/tasks/{id} to track progress.

Change nameservers for up to 25 domains at once. Creates an async task.

Returns a taskId — poll /v1/tasks/{id} to track progress.

Fetch the EPP (auth-info) / transfer code for a single domain synchronously — no task is created.

Registrars differ in how they expose the code:

• API-source registrars (e.g. Dynadot, GName, Spaceship) return the code in the authInfo field of the response. For GName, Most internally creates a tranout record and immediately reads the code off it — the API-level call requires a non-empty sm (reason) field which Most defaults to "Customer requested transfer-out".
• Email-source registrars (e.g. Webnic) only send the code to the registrant's email on file. In that case authInfo is null and recipient is the email address that received it.

Use the source field to branch your UI:

Side effects (best-effort, non-blocking)

A successful fetch also performs two preparation steps so the code is immediately usable for a transfer-out. Failures of either step are logged but do not fail the request — the auth code is still returned.

1. Contact sync. The registrar-side WHOIS is brought in line with the local Contact rows referenced by the domain (registrant / admin / tech / billing). Missing remote contacts are created via the registrar's createContact endpoint; the four roles are then pushed with one bulk replace call. If the WHOIS is already aligned, no replace is issued. This matters because the gaining registrar uses the registrant email for transfer confirmation — a stale email silently sinks the transfer.

2. Transfer-lock clear. For Dynadot and Webnic the registry lock is dropped so the auth code can be handed off immediately. For NICENIC and GName (no programmatic unlock) the lock is left unchanged.

ICANN 60-day transfer lock

Independent of all of the above, ICANN policy forbids transferring a domain out within the first 60 days of registration. Registrars enforce this on their side — GName specifically returns a clean Sorry, The domain registration time is YYYY-MM-DD ..., less than 60 days, it can not be transferred to another registrar message. Most surfaces the registrar's reason verbatim.

For bulk operations across multiple domains, use POST /domains/auth-info instead, which queues an async task and applies the same side effects per item.

Fetch EPP (auth-info) codes for up to 25 domains at once. Creates an async task — track progress and read the codes via GET /tasks/{id}.

Each item's auth code lands in the task's result[i].data once complete:

Code
{
  "domainId": "cm3x4domain001",
  "domain": "example.com",
  "ok": true,
  "data": { "authInfo": "aB3$xY9!kLm", "recipient": null }
}

For email-source registrars (Webnic) authInfo is null and recipient is the email address the code was sent to.

Side effects per item (best-effort, non-blocking)

For each domain in the batch the worker performs two preparation steps so the returned code is immediately usable for a transfer-out. Failures of either step are logged but do not mark the item as failed.

1. Contact sync. The registrar-side WHOIS is brought in line with the local Contact rows for that domain (registrant / admin / tech / billing). Missing remote contacts are created on the fly; the four roles are then pushed with one bulk replace call. Already-aligned WHOIS triggers no replace.

2. Transfer-lock clear. Dropped automatically for Dynadot and Webnic; left unchanged for NICENIC and GName (no programmatic toggle exposed by their APIs).

For a single domain you can use the synchronous GET /domains/{id}/auth-info instead, which skips the task system and applies the same side effects.

Import up to 25 domains that already exist on your registrar account into Most's management. The API kicks off one async migration per item and returns the migration ids immediately — poll GET /domains/migrations/{id} for each one to follow the pipeline.

Optional registrarId (auto-detect)

Each item must carry clientId and domainName; registrarId is optional. When omitted, Most fans out a getDomainInfo call to every connected, active provider account in parallel and uses the first one that confirms it owns the domain. The response's autoDetected: true flag marks items resolved that way, and the chosen registrarId is echoed back.

If the scan finds nothing (the domain isn't on any of your connected accounts), the item goes into failures[] with an explanation rather than spawning a doomed migration. Real per-provider scan errors (rate-limit hits, network issues) are listed under failures[].scanErrors for debugging — surfacing them helps tell "not found anywhere" apart from "GName was throttled mid-scan".

If you already know the registrarId, pass it explicitly: it skips the lookup (and dodges per-registrar rate limits — see Registrar peculiarities).

Migration ≠ transfer-in

This endpoint does not trigger an ICANN registry transfer-in. The domain stays at its current registrar; what changes is who manages it inside Most:

• the four ICANN WHOIS contacts on the domain get rebound to the local Contact rows of the target Client;
• (Webnic only) the domain is relocated under our managed registrant tenant so future API operations route through the connected credentials;
• the local ClientDomain row is created in MIGRATION state and flips to ACTIVE once the pipeline finishes.

Use this when:

• you already own the domain at a registrar Most supports, and you want Most to take over its WHOIS / NS / renewal lifecycle;
• you registered the domain outside Most (panel UI, CLI, partner) and need to reflect that in our DB.

Do not use this for fresh registrations (use POST /domains/orders instead) or for moving a domain between registrars (no API endpoint yet — open a ticket if needed).

Pipeline steps

The worker walks each migration through these steps, exposed verbatim in the step field of GET /domains/migrations/{id}:

Failures at any step move the migration into FAILED with a human-readable errorMessage and leave the partial state for inspection. Use POST /domains/migrations/{id}/retry to resume — the worker continues from the last completed step, not from scratch.

Per-registrar caveats

• Webnic — fully supported including registrant-tenant relocation (uniqueness rule: one tenant per Client × Provider, auto-created during ENSURING_PROFILE with the Client's login as the registrant username hint).
• Dynadot / Spaceship / NICENIC — no tenant concept; the migration stops after REPLACING_CONTACTS. WHOIS is rebound but the registrar's internal owner record (where applicable) isn't.
• GName — single template per domain (one WHOIS shared across all four roles); the worker creates a fresh template from the Client's REGISTRANT contact and rebinds the domain via /api/domain/contact (async, ~30–120 s to actually apply registry-side; the worker polls).

Scan every active provider account the caller has connected and return the one that already owns the supplied domain. Useful as a separate diagnostic step ahead of POST /domains/migrate when you want to inspect the result before kicking off async work — migrate does the same lookup internally when registrarId is omitted.

Per-provider behaviour

The scan calls each adapter's getDomainInfo in parallel (concurrency 4 by default so the stricter registrars don't choke). Clean "domain not in this account" responses are treated as expected and silently dropped. Anything else (rate-limit hit, auth error, network blip) shows up in the errors[] field so callers can tell a true miss apart from a partial scan.

Watch the per-registrar quirks from Registrar peculiarities — in particular GName's /api/domain/info shares the same 1 RPS throttle as /api/domain/check, so don't fire this in a tight loop across many domains at once.

Returns the live state of one migration. The step field tells you exactly where the worker currently is in the pipeline (see POST /domains/migrate for the full step ladder).

Poll this endpoint until status reaches a terminal state (COMPLETED or FAILED). Typical end-to-end runtime is 5–30 seconds on Dynadot / Spaceship / NICENIC, 30 s – 2 min on Webnic (the bulk-replace endpoint is queue-backed registry-side), 1–5 min on GName (their contact rebind is async by spec).

If status === "FAILED", errorMessage carries the failure reason verbatim from the registrar. Use POST /domains/migrations/{id}/retry once the cause is fixed.

Re-queues a FAILED migration without recreating the row. The worker resumes from the last successful step instead of restarting from QUEUED, so contact creation that already succeeded isn't repeated.

The call fails with 409 CONFLICT if the migration is already RUNNING or COMPLETED. Successful retry flips the underlying ClientDomain back into MIGRATION state, resets errorMessage, and publishes the worker trigger.