How Does Domainr's Domain Status API Work?
Updated
Domainr's domain status API checks whether a domain is available by querying domain registry data directly, rather than inferring availability from WHOIS or DNS lookups. According to Domainr, it is the only ICANN-accredited domain status API provider, and its Fastly Domain Research API returns results in milliseconds with no false positives. It's aimed at products that need to embed domain search — registrars, website builders, naming tools — and at security teams monitoring domain status changes.
What the API actually does
The core function is a status check on a given domain string. Instead of a binary available/taken answer, it returns a status that distinguishes between several outcomes:
- Available — registrable at standard pricing
- Premium-priced — registrable, but at a registry-set premium price
- For sale in an aftermarket — listed by a third party rather than the registry
- Taken — registered and not currently listed
This distinction matters because "available" and "cheap" are different questions. A domain can be registrable and still cost far more than a standard registration, and a taken domain can still be acquirable through an aftermarket listing.
Why direct registry access changes the result
Most domain availability checks work by querying WHOIS or DNS and interpreting the response. That approach produces false positives: a domain can appear unregistered in WHOIS while actually being reserved, blocked, or in a grace period. Domainr's claim is that direct, privileged access to registry data eliminates this class of error — the status reflects the registry's own record rather than a derived signal.
The practical consequence is that you can act on the result without a confirmation step. If the API says a domain is available, a registration attempt should succeed; if it says premium, the price is a registry price rather than a guess.
Search and suggestion behavior
Beyond single-domain lookups, the API supports per-keystroke search. As a user types, it returns availability for the typed string and suggests alternative top-level domains when the .com (or whatever was typed) is taken. The suggestions are context-aware — they surface TLDs relevant to the input rather than an arbitrary list.
This is what makes it usable as an embedded search box rather than a batch-checking tool. The intended flow is: user types a name, sees availability across several extensions at once, and can keep iterating without submitting a form.
Filtering and customization
The API is described as filterable by:
| Filter | Use case |
|---|---|
| Extension | Restrict results to specific TLDs |
| Registrar | Scope to a particular registrar's data |
| Location | Region-relevant results |
| Language | Localized suggestions |
It also supports full IDNA and Unicode, so internationalized domain names work without pre-conversion on your side. Domainr notes a drop-in tag option for teams that want search without building the integration themselves.
Who it's for
Two distinct audiences are named:
- Product teams embedding domain search — registrars, app builders, naming or branding tools. The value is conversion: a fast, accurate search that keeps users in the flow instead of sending them to a separate lookup.
- Security and supply-chain teams — monitoring critical domains, getting alerted to status changes, and identifying at-risk domains before they change hands. Here the API is used as a monitoring feed rather than an interactive search.
What to check before adopting
- Access: the API is part of Fastly and requires a Fastly API token. Domainr's page does not state pricing, so treat cost and rate limits as things to confirm with Fastly directly rather than assuming a free tier.
- Coverage: the claim is "every TLD," which is worth verifying against the specific extensions your users care about.
- Latency expectations: "milliseconds" is the stated figure for a status check; per-keystroke search has different performance characteristics, so test it under your own load if you plan to wire it to an input field.
- Monitoring semantics: if you're using it for security, confirm what triggers an alert — a status change, a registrar change, or an expiry event — since those are different signals.