Free or taken — and how sure we are of the answer
Domain & App-Name Availability API returns live Domain & App-Name Availability data as clean JSON for domain & app-name availability The primary endpoint, check, returns domain, available (bool|null), registered (bool|null), confidence (high|medium|low), method, status[] (Domainr-style tokens), note, regis….
5 active endpoints. Every call is 1 credit.
- POST/domain-availability/v1/check
- POST/domain-availability/v1/bulk_check
- POST/domain-availability/v1/rdap
- POST/domain-availability/v1/suggest
- POST/domain-availability/v1/batch
What Domain & App-Name Availability endpoints does ReefAPI ship?
5 live read endpoints. Read-only data API: no writes, no account actions, no dashboard access on the target site.
Domain & App-Name Availability API
3 of 5 endpoints, ready to run
Whether one domain is registered, the method that decided it, a confidence level, the registry status codes and the DNS evidence behind the answer.
{ "ok": true, "meta": { "api": "domain-availability", "endpoint": "check", "mode": "live", "latency_ms": 1209.1, "record_count": 1, "cache_hit": false }, "data": { "domain": "reefapi.com", "tld": "com", "register_url": null, "available": false, "registered": true, "confidence": "high", "method": "rdap", "note": "RDAP registration record exists (authoritative).", "rdap_status": 200, "tld_has_rdap": true, "status": [ "active" ] } }
How the Domain & App-Name Availability API works
Domain & App-Name Availability is a normal ReefAPI surface — the same four rules that hold for every other engine on the key.
No OAuth app, no request signing, no per-site account. One key covers all 184 engines.
Every route is a POST with a JSON body. Parameters are validated against the published schema before anything is charged.
Credits, not seats. Failed and blocked calls are never charged, and cache hits cost nothing.
One envelope everywhere. meta carries latency_ms, record_count and the endpoint that answered.
Naming a product without opening thirty registrar tabs
The real question is never 'is this one domain free'. It is 'of the eight names on the whiteboard, which ones can we actually have, in the extensions we would accept'.
{"name": "myapp", "tlds": "com,io,ai,app,dev"}One call per candidate name instead of one per name-and-extension pair.
{"name": "myapp", "tlds": "com,io,ai,app,dev"}For the names that are all taken. Generated variations come back pre-checked with a registration link on each available one.
A shortlist you can act on rather than a list you still have to verify, with the confidence of each verdict attached so you know which ones to double-check before paying.
curl -X POST https://api.reefapi.com/domain-availability/v1/check \
-H "x-api-key: $REEF_KEY" \
-H "content-type: application/json" \
-d '{"domain":"google.com"}'{
"ok": true,
"data": { … },
"meta": {
"api": "domain-availability",
"endpoint": "check",
"mode": "live",
"latency_ms": …,
"record_count": …
},
"error": null
}How a verdict is reached, and how much to trust it
Every response says not just whether a domain is free but how that was established — method, confidence, rdap_status and a plain-English note. The difference matters: an RDAP answer comes from the registry itself, a DNS answer is an inference. Four measured checks below.
| Domain checked | method · rdap_status | confidence and what it means |
|---|---|---|
| reefapi.com | rdap · 200 | high — the registry holds a registration record. Taken, authoritatively. |
| reefapi.dev | rdap · 404 | high — the registry's own RDAP has no record. Free, authoritatively. |
| reefapi.io | dns · 404, tld_has_rdap false | medium — .io publishes no RDAP server, so the verdict is inferred from NXDOMAIN. The note says outright that it is not registrar-grade. |
| an unregistered .com | dns · -1 | low — the RDAP request itself did not complete, and only DNS evidence remains |
| status[] tokens | active · inactive · undelegated | Domainr-style state tokens; undelegated means no nameservers are published for it |
| register_url | null when taken | populated with a registrar search link only when the domain is free |
rdap_status -1 is not an HTTP status. It means the RDAP call did not complete at all, as opposed to 404, which is a registry answering that it has no such record — and 404 is therefore good news, not an error. That distinction is the whole reason confidence exists as a separate field.
How the verdict is reached, and why 'free' is the harder direction
Measured on registered domains and on names chosen to be free, across .com, .io, .dev and .app. The first two rows are the ones that matter.
The response carries the method, a confidence level, the registry's HTTP status and the DNS evidence side by side. A registry that answered directly gives method rdap and high confidence; a registry that did not answer gives method dns, low confidence, and a note saying the verdict was inferred from the absence of name servers. Same shape, clearly different strength of claim.
Registered domains answered from the registry every time, at high confidence, in one to two seconds. Free names were uneven: .dev and .app returned a clean registry not-found and high confidence, .io returned not-found at medium, and .com names frequently got no registry answer at all and fell back to DNS inference at low confidence — occasionally taking well over ten seconds to get there. The pattern follows the registry, not us. Read the confidence field before treating an available verdict as a decision.
They are not two views of one flag. A domain can be registered but undelegated, or resolve without a public registry record, and the status list plus the DNS block let you see which case you are in rather than forcing it into a yes or no.
The suggest action generated thirty variations on a name and returned twenty-nine of them as available, each with its own verdict, confidence and a registration URL. It is a shortlist rather than a brainstorm — the checking has already happened.
The RDAP action returns the structured registration record directly, and personal contact details stay out of the response unless the call asks for them. Registry data about people is regulated data; the default is the conservative one.
What people build with Domain & App-Name Availability
The jobs this data is most often used for.
endpoints
credit per call
Ops teams use Domain & App-Name Availability to get is one domain available? Combined RDAP and DNS verdict with confidence + Domainr-style status….
Developer tools use Domain & App-Name Availability to get one NAME across many TLDs → availability map (which of name.com/.io/.ai/… are free)..
Validation workflows use Domain & App-Name Availability to get full WHOIS via RDAP for a registered domain (registrar, created/expires, status, nameservers,….
Data-quality teams use Domain & App-Name Availability to get name variations (prefix/suffix/TLD permutations, deterministic.
What Domain & App-Name Availability data costs
The cheapest call here is 1 credit, so $15/mo (Pro) buys 10,000 of them — $1.50 per 1,000 credits. Credits roll over and never expire, and failed or blocked calls are not charged.
Full pricing →- 1,000 free credits on signup, no card
- One key, all 184 APIs, one credit pool
- Failed and blocked calls are never charged
- Credits roll over and never expire
Call it in two lines
Sign up, get 1,000 credits and one key that works on every engine. Then this is the whole protocol.
curl -X POST https://api.reefapi.com/domain-availability/v1/check \
-H "x-api-key: $REEF_KEY" \
-H "content-type: application/json" \
-d '{"domain":"google.com"}'import requests
r = requests.post(
"https://api.reefapi.com/domain-availability/v1/check",
headers={"x-api-key": REEF_KEY},
json={
"domain": "google.com"
},
)
print(r.json()["data"])Have a question? We got answers.
The questions people actually ask before wiring up Domain & App-Name Availability.
Get a free key →available says true but confidence is low. Can I register it?▾
Probably, but do not promise a customer it is free on that evidence alone. Low confidence means the registry could not be reached and the verdict rests on DNS — a measured check returned method "dns", rdap_status -1 and the note "RDAP HTTP -1; DNS-inferred available (NXDOMAIN)". A registered domain with no nameservers looks identical to an unregistered one over DNS. Show the confidence, and gate anything irreversible on a high-confidence rdap verdict or on the registrar's own check at the point of purchase.
Why is .io only ever medium confidence?▾
Because that registry publishes no RDAP server, which the response states as tld_has_rdap false. A measured reefapi.io check returned method "dns" with the note "'.io' has no RDAP server; DNS-inferred: NXDOMAIN / no NS-SOA → available. Not registrar-grade — confirm at a registrar." Compare reefapi.dev in the same bulk call, which came back method "rdap" at high confidence because that registry does publish one. Confidence tracks the TLD's infrastructure, not the name you asked about.
Is a 404 from RDAP an error?▾
No — it is the good answer. A 404 means the registry looked and holds no record, which is the authoritative way to establish that a domain is free; the measured reefapi.dev check returned rdap_status 404 with confidence high. A 200 means a record exists, so the domain is taken. The failure case is -1, which means the request never got an answer at all. Read method and confidence rather than mapping status codes yourself.
What is in the WHOIS record, and is registrant data included?▾
A measured RDAP lookup on google.com returned the registry domain id, registrar "MarkMonitor Inc." with registrar_iana_id 292, six status codes, created 1997-09-15T04:00:00Z, updated, expires 2028-09-14T04:00:00Z, four nameservers in upper case, dnssec false and an abuse contact with email and phone. No registrant block came back: most gTLD registries redact registrant details, so build on the registrar, the dates and the nameservers, which are always published. All dates are ISO-8601 UTC with a Z.
What do the status tokens mean?▾
status[] carries Domainr-style state tokens describing the name, while whois.status carries the registry's own EPP codes — two different vocabularies in one response. Measured: a registered domain returned status ["active"] with whois.status ["client transfer prohibited"], and free domains returned ["inactive", "undelegated"]. undelegated means no nameservers are published, which is normal for an unregistered name and also true of a parked one, so it is not by itself proof of availability.
How do I check one name across many extensions?▾
bulk_check takes a bare name and a tlds list and returns a per-TLD verdict plus an available[] shortlist and available_count, so a single call answers 'which extensions can I still get'. Each row carries its own method, confidence and note, and they genuinely differ within one call — a measured run over com, io, dev, ai and xyz mixed high-confidence RDAP verdicts with medium-confidence DNS ones. batch is the sibling for a list of full domains rather than one name, and it separately returns invalid[] for inputs it rejected.
What does suggest do that bulk_check does not?▾
It generates candidate names around the one you gave rather than only varying the extension, and it returns each suggestion with the same full verdict attached, sorted available-first. That means you never have to check a suggestion afterwards — the availability answer arrives with it. Use bulk_check when the name is decided and you are choosing an extension, and suggest when the name itself is still open.
What is the Domain & App-Name Availability API?▾
Domain & App-Name Availability API is a ReefAPI endpoint group for domain & app-name availability It returns live JSON through POST requests under /domain-availability/v1.
Is the Domain & App-Name Availability API free to try?▾
Yes. ReefAPI starts with 1,000 free credits, no card required. Domain & App-Name Availability calls use the same shared credit balance as every other ReefAPI engine.
Do I need a Domain & App-Name Availability login or account?▾
No login to Domain & App-Name Availability is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.
How fresh is the Domain & App-Name Availability data?▾
The page example is captured from a live check call, and production requests fetch live data through ReefAPI rather than a static sample.
How many credits does the Domain & App-Name Availability API use?▾
Domain & App-Name Availability actions currently cost 1 credit per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.
Can I call Domain & App-Name Availability from an AI assistant or MCP client?▾
Yes. Connect ReefAPI once through MCP and your assistant can call domain-availability actions with the same key, credit pool and JSON envelope used by normal REST requests.
Is the Domain & App-Name Availability API a Domain & App-Name Availability scraper?▾
It is the managed alternative to a DIY Domain & App-Name Availability scraper. Instead of building and maintaining your own scraper — proxies, headless browsers, captcha and constant breakage — you call one ReefAPI endpoint and get the same domain & app-name availability back as clean JSON.
19 Utilities & AI APIs on the same key
One key, one credit pool, one response envelope. If you are pulling Domain & App-Name Availability, you are one call away from the rest of the category — no second contract, no second integration.
Need something this API does not do?
Name the endpoint, the field, or a source we do not carry yet. We ship new APIs every week and you would be first to get the key. Real people read every message and reply the same day.
Try it on your own data before you pay anything
The call above is the real endpoint, not a recording. A free key gives you 1,000 credits, the other 183 APIs, and the same envelope everywhere.
Endpoints, parameters and credit costs on this page are read from the live catalog and cannot drift from what the API accepts. Field notes were captured on 2026-08-30.