Checking Domain Availability and Price Without a Token: Vercel API vs RDAP

On 2026-09-28, Vercel published a changelog entry titled “Search domains without authentication”: its Domains Registrar API now checks up to 200 exact domain names in one request, returning registerable status plus registration and renewal prices, with no API token required. That removes the credential-storage problem for anyone wiring domain checks into a script, CLI, or agent tool, but only for names you would buy at Vercel’s registrar. RDAP, the standardized WHOIS successor, remains the vendor-neutral alternative that returns status with no prices at all.

What changed on 2026-09-28

The Vercel changelog is specific about the new boundary: “With the Domains Registrar API, check up to 200 exact domain names in one request. The response shows whether each can be registered and, when available, its registration and renewal prices.” The same entry states that “authentication is still required to buy or manage domains,” so the auth boundary moved rather than disappeared. Read-only lookups are anonymous; anything that spends money or mutates state still needs a credential.

For a developer wiring an availability check into a CI job or an LLM agent’s tool list, this is the relevant shift. Previously, even a read-only “is this name taken?” call meant provisioning a Vercel token, storing it somewhere, and accepting the blast radius if it leaked. A tokenless search path removes that entire category of operational work for the lookup step. Compare the pattern we covered in Vercel’s Billing Usage API: there, the workaround for avoiding a long-lived token in CI was routing calls through the vercel api CLI’s existing session. Unauthenticated search sidesteps the problem entirely for this one read path.

Two things the changelog does not say, and which matter before you ship anything against it: the rate limit on the unauthenticated path, and which TLDs it covers. The changelog is silent on both, and silence in a vendor announcement is not a guarantee of no limits; those remain [unverified] until the API documentation is checked.

What the Vercel response actually gives you

The payload, per the changelog, has two components. First, a per-name registerable flag: an explicit answer to “can this be registered,” not an inference you draw from an HTTP status code. Second, registration and renewal prices “when available.” That qualifier deserves attention. It implies prices are not guaranteed for every name in the batch, and the changelog does not define the conditions under which pricing is absent.

Read the availability answer as scoped, not global. “Can be registered” from Vercel’s Domains Registrar API means can be registered through Vercel’s registrar, at the price Vercel quotes. It does not establish that a name is unavailable elsewhere, or that another registrar would quote the same number. This is not a criticism, it is what any registrar endpoint can truthfully answer, but a tool that treats the response as a universal statement about the name would be wrong.

The price side has its own nuance. Registration and renewal prices are separate figures, and renewal is the one that compounds. Registrar pricing also carries term constraints that an availability-plus-price endpoint may not surface: per Hostinger’s domain search page, the minimum registration period is one year, but some TLDs such as .ai require a two-year minimum. So a returned price is registrar-specific and term-specific, and a comparison tool that displays it without the term is displaying half a fact.

The RDAP baseline: status, no prices, no token ever

RDAP (Registration Data Access Protocol) is the ICANN-standardized successor to WHOIS. As one community walkthrough describes it, RDAP replaces WHOIS’s free-text responses with standardized JSON returned over HTTP/HTTPS as a RESTful API. Deployment is not new: the same source notes PSI-Japan has operated an RDAP lookup service since 2019-08-26, and WHOIS itself is a legacy protocol at this point, not a peer option for new integrations.

Three properties define RDAP as the comparison path here. It is an open standard, not a vendor endpoint. It requires no credentials for the queries at issue. And it carries no pricing data whatsoever; registration data, not retail data, is the protocol’s domain.

Coverage is the bound. Per client.rdap.org, “all generic TLDs now support RDAP, but only a few ccTLDs have deployed RDAP so far.” If your checks target .com, .net, or other gTLDs, RDAP is a complete fallback. If they target country-code TLDs, coverage becomes a per-TLD question you have to verify yourself. The standards trajectory favors closure of that gap over time: ICANN required contracted parties to bring RDAP services into full compliance with STD 95 and the 2024 gTLD RDAP Profile by 21 August 2025, according to a second community walkthrough covering the migration.

Availability semantics: explicit flag vs 404 inference

This is the sharpest technical difference between the two paths, and the one most likely to produce a bug.

Vercel’s endpoint answers the question directly. The response tells you whether each name can be registered. Your code reads a field.

RDAP has no “available” field. Availability is inferred, as one zenn.dev walkthrough shows: query the registry’s RDAP server for the domain object, and if you get a registration record back, the domain exists and is taken; if you get an HTTP 404, the object does not exist, which usually means the name is free. “Usually” is doing real work in that sentence. The same zenn.dev walkthrough documents a live counterexample: on 2026-05-28, GMO Internet’s Onamae RDAP server answered a query for kobedenshi.ac.jp with a 404 whose error body read “Onamae does not support forward domain queries.” That 404 says the server declined the query type. It says nothing about whether the domain is registered.

The practical rule for any RDAP-based availability check: never map 404 to “available” without inspecting the error body. A 404 with an empty or not-found description on a supported query is evidence of availability; a 404 with an unsupported-operation description is no evidence at all. Code that treats the status code alone as the signal will silently misreport names in exactly the ccTLD space where RDAP coverage is already thin.

Privacy, batching, and what each query reveals

The query-privacy axis is easy to overlook and genuinely different between the paths. A lookup through client.rdap.org connects the browser directly to the registry’s RDAP server over HTTPS, so only the relevant registry sees the query; the sponsoring registrar sees it only if you enable the referral-following option, per the tool’s own description. A vendor-API lookup, by construction, discloses every name you check to the vendor. For someone evaluating names for an unannounced product, that distinction can matter more than any price field. (An RDAP client you run yourself queries registries directly the same way; the client.rdap.org description characterizes the model, not a property unique to that site.)

Batching cuts the other way. Per the changelog, Vercel checks up to 200 exact names per request. RDAP is one object per lookup, so a 200-name sweep is 200 requests against however many different registry servers your TLD mix touches, each with its own behavior. For bulk screening, the vendor endpoint is structurally more convenient; for a single sensitive name, the neutral path reveals less.

Decision table

Which to wire in, and what to check first

The split follows from what each path can truthfully return. If your tool needs bulk screening with prices attached, an agent that proposes ten name candidates and ranks them by cost, a CI step that validates a list, Vercel’s unauthenticated search answers that in one call, and the credential problem it solves is real. Accept that the answer is scoped to Vercel’s registrar, display registration and renewal as separate numbers with terms attached, and treat the coupling as a chosen dependency.

If your tool needs a neutral, durable “does this registration exist” answer, especially one that must not disclose queries to a commercial party, or that will outlive any single vendor relationship, RDAP is the better foundation, with two implementation obligations: check the error body before reading 404 as available, and verify per-TLD support if ccTLDs are in scope. Many tools will want both: RDAP as the neutral status layer, the vendor endpoint as the pricing layer, with no assumption that the two signals are interchangeable.

Before shipping against the Vercel path, two verifications are outstanding as of this writing: the rate limit applied to unauthenticated requests, and the TLD list the search covers. Neither appears in the changelog, and neither should be assumed. The strongest limitation on this whole comparison is that both paths’ “available” signal carries a caveat, Vercel’s is registrar-scoped, RDAP’s is an inference with a documented failure mode, so whichever you pick, the availability answer deserves one more line of code than it first appears to need.

Frequently Asked Questions

Does the Vercel Domains Registrar API require a token for availability checks?

its Domains Registrar API now checks up to 200 exact domain names in one request, returning registerable status plus registration and renewal prices, with no API token required.

Does RDAP return domain registration prices?

RDAP, the standardized WHOIS successor, remains the vendor-neutral alternative that returns status with no prices at all.

How many domain names can be checked in one Vercel API request?

With the Domains Registrar API, check up to 200 exact domain names in one request. The response shows whether each can be registered and, when available, its registration and renewal prices.