Short answer
Use a whois API when you need on-demand lookups for domains a user supplies, typically under a few thousand a month. Use a bulk whois database download when you need every newly registered domain each day — bulk delivery is dramatically cheaper per record, has no rate limits, and supports offline filtering and joins.
Key takeaways
- APIs are priced per query; bulk feeds are priced per month. Volume decides the winner.
- You cannot discover new domains with an API — you must already know the domain to ask about it.
- Bulk files support SQL-style filtering, joins and backfill; APIs do not.
- Rate limits make bulk enumeration through an API impractical at daily-feed scale.
- Many mature stacks run both: bulk for discovery, API for on-demand verification.
These two products are often compared as if they were substitutes. They are not. One answers "tell me about this domain I already know about", and the other answers "tell me about every domain that came into existence yesterday". Choosing the wrong one produces either a surprising invoice or a capability you never actually get.
The fundamental difference: pull versus push
A whois API is a pull model. Your application supplies a domain name, the service returns that record. It is excellent inside a product — a registrar checkout, a security tool that enriches an alert, a form that validates a domain a user typed. It is useless for discovery, because you can only ask about domains you already know.
A bulk whois database download is a push model. The provider collects everything, cleans it, and delivers the complete daily set to your FTP account. You did not need to know any domain names in advance — discovery is the product.
Side by side
| Dimension | Whois API | Bulk database download |
|---|---|---|
| Pricing model | Per query, tiered credits | Flat monthly subscription |
| Cost at 200k records/day | Prohibitive | Fixed and predictable |
| Discovery of new domains | Not possible | Core capability |
| Rate limits | Always present | None — it is a file |
| Latency | Seconds per lookup | Daily batch |
| Filtering and joins | Client-side, one record at a time | Native, over the whole day at once |
| Backfill / history | Rarely available | 30+ days on the server |
| Integration effort | HTTP client | Scheduled FTP fetch and unzip |
| Best for | On-demand enrichment inside a product | Lead generation, NRD security, research |
Where the cost curve crosses
Per-query APIs are typically economical up to a few thousand lookups a month. Past roughly ten thousand, the credit spend starts to rival a flat-rate bulk subscription; at daily-feed volumes it is not close. If your requirement contains the phrase "all new domains", the API path is already the wrong one — you would be issuing 200,000 requests a day against rate limits that are specifically designed to prevent exactly that.
A quick test
Do you know the list of domains you want to ask about before you start? If yes, an API may fit. If the list is the thing you are trying to obtain, you need the bulk download.
Matching the tool to the job
| Use case | Right tool |
|---|---|
| Daily B2B leads from new registrations | Bulk download |
| Validating a domain a user typed into your signup form | API |
| Blocking newly registered domains at the DNS layer | Bulk download |
| Enriching a single SIEM alert with registrant detail | API |
| Trademark monitoring across all new registrations | Bulk download |
| Checking expiry on your own portfolio | API |
| Registrar market-share research | Bulk download |
| Whois lookup against your own supplied domain list | Custom bulk scrape |
The hybrid pattern most mature teams end up with
- 1Bulk daily feed provides discovery — every new domain, cleaned and proxy-removed.
- 2Filtering and scoring happen offline against the full day, where joins are cheap.
- 3Only the small qualified subset is re-verified through an API at the moment of action.
- 4Historic bulk files are retained for retrospective analysis the API could never provide.
This keeps API spend proportional to actions taken rather than records examined, which is the shape you want.
The third option: custom whois scraping
There is a middle path that gets overlooked. If you already hold a list of domains — a customer base, a competitor portfolio, an acquisition target list — a provider can run whois collection against your specific list and return a single structured file. That is cheaper than the equivalent API credits, faster than writing your own rate-limit-respecting crawler, and returns exactly the field set you asked for. GetWhoisData offers this as a custom whois data job alongside the daily database.
Frequently asked questions
Is a whois API cheaper than a bulk whois database?+
Only at low volume. APIs are economical up to a few thousand lookups a month; above roughly ten thousand a flat-rate bulk subscription becomes cheaper, and at daily-feed volumes of 200,000 records the API approach is not viable on cost or rate limits.
Can I get a list of newly registered domains from a whois API?+
No. An API returns data for a domain you supply, so it cannot discover domains you do not already know about. Discovery requires a bulk feed of newly registered domains.
What is the fastest way to whois-lookup a list of domains I already have?+
A custom bulk whois scrape against your supplied list. It returns one structured file with the fields you specify, and avoids both API credit costs and rate-limit engineering.
Do bulk whois downloads have rate limits?+
No. The data is delivered as files over FTP or web access, so there are no per-query limits. With GetWhoisData the number of downloads is also unlimited for the subscription period.
Can I use both a bulk feed and an API together?+
Yes, and most mature teams do. Bulk handles discovery and offline filtering across the full day, and an API re-verifies only the small qualified subset at the moment you act on it.