How to Bulk Look Up WHOIS / RDAP Domain Data in 2026

You have a list of domains — a portfolio to renew, a set of competitor names, a batch of suspicious domains from a threat feed — and you need their registration data. Classic WHOIS makes this painful: every registry returns free-form text in its own quirky format, and paid WHOIS APIs charge per lookup and gate everything behind a key. This guide covers the modern path: query RDAP, the structured JSON successor to WHOIS, in bulk, with no API key and one flat row per domain.

What’s worth extracting

Each domain comes back as one flat record of about 11 fields, ready to drop straight into a spreadsheet or pipeline:

• domain — the normalized domain that was queried.
• registrar — the accredited registrar managing the domain.
• createdDate — ISO 8601 registration/creation date (your domain-age signal).
• updatedDate — ISO 8601 date the record was last changed.
• expiryDate — ISO 8601 expiration date (sort on this for a renewal calendar).
• status — comma-joined EPP status codes, e.g. clientTransferProhibited, clientDeleteProhibited.
• nameservers — comma-joined nameserver hostnames.
• registrantOrg — registrant organization when public; frequently null under GDPR redaction.
• rdapServer — the authoritative RDAP host that actually answered the query.
• error — "no RDAP data" (or an HTTP error) when nothing could be retrieved; otherwise null.
• checkedAt — ISO 8601 timestamp of when the lookup ran.

The error field is deliberate: a domain with no RDAP service returns a clean row with error set instead of crashing the run, so your output always accounts for every input domain.

How RDAP works (and why it beats WHOIS)

WHOIS data has always been scattered across hundreds of registries, each emitting its own free-text layout — which is exactly why WHOIS parsers are so brittle. RDAP (Registration Data Access Protocol) is the IETF-standardized successor: clean, structured JSON over HTTPS, consistent across registries. It’s what the industry is migrating to.

The lookup flow per domain is straightforward:

1. Normalize the input to a bare registrable domain — scheme, path, www. and ports are stripped, and duplicates removed. You can paste full URLs and messy input; it’s cleaned automatically.
2. Query https://rdap.org/domain/<domain>. The rdap.org bootstrap service looks up which registry owns that TLD and redirects to the authoritative RDAP server; redirects are followed automatically.
3. Parse the JSON: events map to the dates, entities to registrar and registrant, nameservers to hostnames, status to the EPP codes.
4. Retry 429 and 5xx responses up to four times with exponential backoff and a fresh proxy IP.
5. Push one flat row per domain to the dataset.

The whole thing is pure HTTP — no headless browser — with configurable concurrency up to 50. A minimal run is just a domain list:

{
  "domains": ["google.com", "openai.com", "apify.com", "github.com"],
  "maxConcurrency": 10,
  "proxyConfiguration": { "useApifyProxy": true }
}

Because input is cleaned, you can throw raw URLs at it and let it reduce them:

{
  "domains": [
    "https://www.stripe.com/pricing",
    "www.cloudflare.com",
    "notion.so",
    "vercel.com"
  ],
  "maxConcurrency": 30
}

▶ Run the Bulk WHOIS / RDAP Lookup on Apify — paste thousands of domains, get registrar, creation and expiry dates, status and nameservers as one flat row each. No API key, no signup. Export to JSON, CSV, Excel or JSONL.

The access reality

There’s no anti-bot wall here — RDAP is published for public query — but two real constraints shape how you run it.

• RDAP coverage depends on the TLD. All major gTLDs (.com, .net, .org, .io, .dev, .app, etc.) and most modern registries are fully supported. Some country-code TLDs (ccTLDs) don’t run an RDAP server yet — those domains return a clean row with error: "no RDAP data" instead of failing the run. Filter on error to see which domains need a fallback method.
• Servers throttle heavy traffic. Some authoritative RDAP servers rate-limit. That’s the tension behind maxConcurrency: higher (up to 50) is faster, but push too hard on a single registry and you’ll see 429/5xx. When that happens, lower the concurrency — the built-in proxy rotation plus a gentler rate almost always clears it. For sensitive registries, a value of 3 keeps things polite.

There’s also a privacy reality baked into the data: since GDPR, most registries redact registrant personal data, so registrantOrg is frequently null for .com/.net and European domains even when every other field is present. Registrar, dates, status, and nameservers are nearly always there; the registrant name usually isn’t.

Example output

One representative record (status and nameservers truncated for readability):

{
  "domain": "google.com",
  "registrar": "MarkMonitor Inc.",
  "createdDate": "1997-09-15T04:00:00Z",
  "updatedDate": "2019-09-09T15:39:04Z",
  "expiryDate": "2028-09-14T04:00:00Z",
  "status": "clientDeleteProhibited, clientTransferProhibited, clientUpdateProhibited",
  "nameservers": "ns1.google.com, ns2.google.com, ns3.google.com, ns4.google.com",
  "registrantOrg": null,
  "rdapServer": "rdap.markmonitor.com",
  "error": null,
  "checkedAt": "2026-06-15T12:00:00.000Z"
}

Note registrantOrg: null even for a domain as public as this — that’s the GDPR redaction in action, not a scraper miss.

Typical use cases

• Domain investing & drop-catching — bulk-check expiry dates and status codes across thousands of candidate names to find drops, expiring assets, and transfer-locked domains.
• Expiry monitoring — feed your whole portfolio and sort the expiryDate column into a renewal calendar; schedule it weekly so nothing lapses silently.
• Lead generation & B2B enrichment — append registrar, createdDate, and nameservers to a list of company domains to infer hosting, tech stack, and how established a business is.
• Brand protection — audit who registered look-alike or typo-squat domains and exactly when they were created.
• Security & due diligence — a recent createdDate and unusual nameservers are classic phishing/malware signals; bulk-screen suspicious domain lists at scale.

The value across all of these is being able to profile a whole portfolio at once rather than pasting domains into a web form one at a time.

Cost / effort math

Rolling your own bulk RDAP client sounds trivial until you hit the edges: the bootstrap-to-authoritative redirect chain, per-registry throttling that demands backoff plus IP rotation, GDPR-shaped inconsistency in the response bodies, and the ccTLDs with no RDAP at all that will crash a naive loop. Getting a clean, complete row for every input — including the failures — is most of the work.

The managed actor runs pay-per-result — you pay per domain looked up, a fraction of a cent each, with no separate platform fee and no WHOIS SaaS subscription. For a portfolio of a few thousand domains checked weekly, that’s a few dollars a month, with the redirect handling, retries, proxy rotation, and graceful error rows already solved.

Common pitfalls

• Expect registrantOrg to be null. GDPR redaction hides registrant identity on most gTLD and EU domains. If you’re building lead-gen around registrant names, that field will disappoint — use registrar, createdDate, and nameservers for enrichment instead.
• ccTLDs may return no data. A .dk, .jp, or similar without an RDAP server returns error: "no RDAP data". Filter error and fall back to another method for just those rows.
• Tune concurrency to the registry, not the run. A high maxConcurrency hammering one registry (say, a list of all-.com domains) can trigger 429s faster than a mixed-TLD list. Drop it if errors climb.
• Dates are ISO 8601 with timezones. expiryDate and friends come back as full ISO timestamps (often Z). Parse them as datetimes, not date strings, before you sort a renewal calendar.
• status is a joined string, not an array. EPP codes arrive comma-joined in one field. Split on comma if you need to test for a specific lock like clientTransferProhibited.
• Normalize before dedup upstream too. The actor strips www., schemes, and paths, but if you’re merging results back against your own list, join on the normalized domain it returns, not your original raw input.

Wrapping up

RDAP turned domain registration data from a hundred bespoke text formats into one clean JSON schema — and querying it in bulk over the public rdap.org bootstrap means no API key, no SaaS bill, and one flat row per domain. Sort by expiryDate for a renewal calendar, filter on createdDate for freshly registered domains, and let the graceful error rows account for the ccTLDs that don’t answer. If you’d rather not maintain the redirect and retry logic yourself, the managed actor already keeps it green.

▶ Open the Bulk WHOIS / RDAP Lookup on Apify — one run turns thousands of domains into a flat table of registrar, dates, status and nameservers. No API key, no headless browser, export to JSON / CSV / Excel / JSONL. Start on Apify’s free monthly credit.