What checking 100,000 domains usually looks like
You have a list. Maybe it is 50,000 brand variants you want to monitor, maybe it is the long tail of an AI-generated naming run, maybe it is a competitor research dump. The shape is the same: a CSV with a few hundred thousand rows, and a question — which of these are available?
Open any of the usual suspects — GoDaddy, Namecheap, WhoisXML, Domainr — and the answer comes with strings attached:
- The call cap. Most APIs top out at a few hundred domains per request; the most generous I am aware of, Namecheap, accepts around 5,000. Even at that cap, a 100k list is 20 separate requests you have to orchestrate, retry, and reconcile — and most of the field is much smaller.
- The orchestration tax. Now you are writing retry logic, backoff, a queue, idempotency keys. That code is not solving the actual problem.
- The flat bill. Whether a domain was trivially answered by a DNS lookup or required a full WHOIS round-trip, you pay the same per-check rate. The cheap ones subsidise the expensive ones, and you pay for both.
Each of those is a workaround for a constraint that does not have to exist.
What we built instead
A single endpoint that accepts up to a million domains in one body, streams results back as they resolve, and runs each input through a four-stage pipeline:
Bloom filter → DNS → RDAP → WHOIS
cheapest most thoroughEach stage produces an answer or escalates. The query stops at the first definitive result. You are billed at the rate of the stage that answered. Not the stages above it — those did not have a price tag in the first place. Not the stages below it — they were never run.
What that means in plain terms:
- A
.comthat is clearly taken or clearly free gets resolved at the Bloom filter rate, instantly, with zero outbound network calls. This is the floor of our pricing. - A domain that needs to verify a real DNS response gets resolved at the DNS rate.
- A TLD without Bloom coverage, or an ambiguous DNS answer, escalates to RDAP — modern WHOIS over HTTPS.
- The remainder — registries that do not implement RDAP, or queries that need parsed registrant data — fall through to a WHOIS lookup.
No polling, no pagination, no retry plumbing on your side. Results stream back as the pipeline drains.
A worked example
A representative run on 100,000 .com domains in a typical mixed list — some clearly free, some clearly taken, some weird:
| Resolved by | Share | Why |
|---|---|---|
| Bloom filter | ~85% | .com Bloom coverage is dense and accurate. |
| DNS | ~10% | Needed to confirm an active resolver. |
| RDAP | ~4% | Registry needed for parsed status flags. |
| WHOIS | ~1% | Edge cases, older TLDs, parked exotica. |
If you priced this against a flat-rate competitor at, say, $0.005 per check, you would pay $500 for the 100,000 calls regardless of difficulty. The DomainRadar bill on the same list, with 85% of the work resolved at the cheapest tier, comes in at roughly an order of magnitude lower. The exact number depends on your tier and the mix of TLDs — but the principle is fixed: easy domains are billed easy, hard domains are billed hard, and the only thing you ever pay for is the step that answered.
For lists that skew toward newer or less common TLDs (Bloom coverage drops, more DNS and RDAP traffic), the ratio shifts and the bill grows. That shift is the point. The cost reflects the actual difficulty of the question you asked, not a flat fee that assumes every domain is equally hard.
What this leaves you free to ignore
Once the API takes a million domains at a time and streams answers back, a lot of code stops needing to exist on your side:
- No rate-limit handling. One request, one connection, one stream.
- No retry/backoff logic. Pipeline failures retry inside DomainRadar; you see the final result.
- No batch orchestration. No “split list into chunks, fan out, collect, reconcile.”
- No deduplication ledger. A domain submitted twice in the same request resolves once.
That is several hundred lines of code you do not write, do not have to maintain, and do not get paged about at 3am.
Why we built it this way
We needed bulk domain checking for our own product work — naming runs for clients, brand monitoring across portfolios, infrastructure inventory. The off-the-shelf options either capped us, billed us flat regardless of difficulty, or both. The pipeline shape — cheapest method first, escalate only when needed, bill at the answering tier — is the design we wanted to use ourselves and could not buy.
That is the same pattern behind every other Norcube product — we wrote about it in Why we built Norcube. Build for yourself first, ship what you would actually pay for.
So we built it, ran it in production, and made it available.
Try it yourself
Create a free Norcube account and run a list through the bulk endpoint. The free tier covers 500,000 checks every month — split across the pipeline so the cheap tiers do not subsidise the expensive ones and the budget cannot accidentally burn through on a single bad list. Full pricing and the API contract live on the DomainRadar product page and in the docs.
DomainRadar is part of the Norcube platform. Learn more about DomainRadar.