Tools
Utility endpoints that make integration work less tedious. None of them mutate anything — they're pure lookups, generators and diagnostics you can hit freely from a development environment.
They all live under https://api.most.ac/v1/tools and take the same Authorization: Bearer bk_... header as the rest of the API.
| Endpoint | What it answers |
|---|---|
GET /tools/rdap | Who a domain is registered to, straight from the registry |
GET /tools/dns | Why a domain's DNS is or isn't working, and how far a change has propagated |
GET /tools/ns | Whether a nameserver host is actually usable (one or many) |
GET /tools/countries | ISO codes and phone calling codes |
POST /tools/generate-contact | A plausible fake contact, for testing only |
Full request/response schemas live in the API reference. This page covers when to reach for which.
Diagnostics
These three power the same tooling the Most panel uses, so an integration sees exactly the verdicts an operator does.
RDAP — who owns it
Code
RDAP is WHOIS's structured successor. Most resolves the authoritative RDAP server for the TLD through the IANA bootstrap and queries it directly, falling back to rdap.org only if that fails — so you get the registry's own answer rather than a re-publisher's.
The response carries a normalised parsed object (registrar, statuses, key dates, nameservers, abuse contact) and the untouched registry payload in raw.
found: false together with an rdapError is a valid answer — the registry replied and has no record. Treat it as "not registered", not as a failure.
Cached for 30 minutes; pass refresh=1 to bypass. The cache is not just an optimisation — several registries rate-limit RDAP aggressively per source IP.
Not every TLD publishes RDAP at all. For those (.ac is one) you get found: false with an rdapError — the query was answered, there is simply no RDAP service behind that zone.
DNS — why it isn't working
Code
Walks the entire delegation and reports where it breaks, rather than just failing:
- Registry delegation — does the parent hand out nameservers at all?
- Parent/child NS match — does the registry's list agree with what the zone publishes?
- Glue records — do in-zone nameservers have glue at the parent?
- Nameserver resolution — do the hosts resolve?
- Port 53 — are they reachable over TCP and UDP?
- Authoritative answer — do they actually answer for the zone?
- Zone consistency — do the SOA serials agree across nameservers?
Each step reports ok: true | false | "warn" with a human-readable detail. healthy is true only when every step passes.
The same call returns propagation[] — what a dozen public resolvers worldwide (Google, Cloudflare, Quad9, Yandex, AdGuard, Alibaba…) answer right now for the record type you asked about. That is how you distinguish "my change hasn't propagated yet" from "my change is wrong".
Cached for 5 minutes; refresh=1 forces a fresh run.
NS — is this nameserver usable
Code
Takes a nameserver host, not a domain: does it resolve, and does it answer as a nameserver. Run it before submitting nameservers on a domain — an unusable host is the most common reason a registrar rejects an NS change.
It is deliberately lenient, and the reasons matter:
- No glue requirement. Out-of-zone nameservers (say
ns1.cloudflare.comon your domain) correctly have no glue. Demanding it would fail perfectly valid setups. - Any DNS reply counts as answering. Shared and anycast nameservers frequently refuse an SOA query for their own hostname while serving millions of zones happily.
- No port ping. A TCP probe from a single vantage point proves little and false-fails behind filtering.
Checking a whole nameserver set
Pass hosts instead of host to validate several at once (comma or space separated, up to 20):
Code
You get { results, total, valid } rather than the flat single-host shape — the form follows the parameter you used, so adding a second host never changes the response of an existing call. Hosts are checked concurrently, and one bad host doesn't fail the batch: it returns ok: false with its own error while the others report normally.
Countries
Get the full list of countries with their ISO codes and phone calling codes. Useful when:
- Populating a country dropdown in your UI
- Validating user-supplied phone numbers against their country
- Looking up the
+CC.prefix for contact creation
Code
Code
The list is static and sorted alphabetically by name. It's built from the ITU country calling codes shipped with libphonenumber-js, so every code is guaranteed to be a valid E.164 country.
Generate Test Contact
For testing only
Most registrars require real, accurate WHOIS data — using fake contact data in production registrations is a policy violation and can get your accounts suspended or domains blocked. This endpoint exists for integration testing only: building out your API client, exercising the contact create flow in sandbox, regression tests, etc.
Never use the output of this endpoint for real domain registrations. Always collect real contact data from your end users before calling POST /v1/orders.
Generate a realistic fake INDIVIDUAL contact for use in testing. The generator picks a random country, produces a name / address / phone number that actually looks native to that country, and assigns an email from one of your verified mail domains.
The returned email is guaranteed unique — it's cross-checked against the contacts table before being returned, so you can directly pass it to POST /v1/clients/{clientId}/contacts without worrying about duplicates.
Code
Code
Forcing a specific email domain
By default the generator uses your first verified mail domain for the email. Pass emailDomain in the body to override:
Code
Fallback when no mail domains are configured
If the caller has no online mail servers and you don't pass emailDomain, the generator returns @mail.example as a clearly-non-deliverable placeholder. Swap it out before creating a real contact — the email has to belong to a domain you actually control.
Uniqueness guarantee
The generator runs a count query against the contacts table before returning. If the generated email already exists (unlikely — the generator appends 3 random digits to every name), it regenerates up to 10 times. After 10 collisions it appends an 8-hex suffix that makes collision astronomically unlikely.
Typical usage flow (testing only)
This example is for local/sandbox testing only. The generate-contact endpoint produces fake data that violates registrar WHOIS accuracy requirements — never feed it into POST /v1/orders against production registrar accounts.
Code
This is the quickest way to wire up an integration test against the API — start with an empty account, get a fully-populated client + registrant in seconds, exercise the rest of your flow against sandbox endpoints. Always swap in real contact data before touching production registrars.