Domain RDAP Lookup

You give this actor a list of domains. For each one, it queries RDAP — the ICANN-mandated, standardized JSON replacement for WHOIS — through the public rdap.org bootstrap redirector, which resolves any domain to its authoritative registry RDAP server and returns the registration record live. You get back registrar, registration and expiry dates, nameservers, DNSSEC signing status, and the registrar's abuse contact, as one flat row per domain. No API key, no scraping, no cached snapshot — RDAP was built to be machine-queryable, so this hits structured JSON directly instead of parsing free-text WHOIS output.

RDAP replaced WHOIS across gTLDs starting in 2019 precisely because WHOIS output was never standardized — every registrar formatted its response differently, and there was no common way to tell a script "this is the expiry date" versus "this is a comment line". RDAP fixes that: every registry that supports it returns the same JSON shape, with named fields for registrar, dates, status codes, and nameservers. This actor reads that JSON straight, without needing to know in advance which registry a given domain belongs to — rdap.org's redirector figures that out from IANA's bootstrap file and forwards the request.

Who it's for

The accountable_eel catalogue sells company intelligence columns for outbound. Each actor takes a list of domains or company identifiers and returns one flat, stably-named row per input — firmographics, registry IDs, tech stack, email route, hiring activity — the shape a Clay table, an n8n workflow, or an AI agent can consume without post-processing. Pricing is pay-per-event and per-domain: a few tenths of a cent for a row that was actually found, and nothing for a miss, so a list that doesn't enrich costs you next to nothing. Where an official source exists — VIES, GLEIF, SEC EDGAR, Brønnøysund, PRH, RDAP — it is queried directly instead of scraped. No seat licence, no monthly minimum, no credit system to decode.

This one is for registration-record lookups specifically: domain expiry monitoring, registrar and nameserver checks, and abuse-contact discovery, run over a list instead of one domain at a time in a browser tab.

Why this one

• Structured JSON, not scraped or parsed WHOIS text. RDAP is a standardized protocol with a fixed JSON schema per registry — no regex against free-text WHOIS output that changes format by registrar.
• No key, no account, no rate-limit negotiation on your end. rdap.org's public bootstrap redirector resolves the right authoritative server per domain and returns the answer in the same request.
• Never charged for a domain with no registration data. Unregistered domains and registries with no RDAP server still get a row ("found": false), so your dataset always has one row per input — you just don't pay for it.
• Runs as a batch. Paste hundreds or thousands of domains, get back a dataset instead of running whois in a loop and parsing the output yourself.
• DNSSEC and abuse contact in the same row as the registrar dates. Most manual WHOIS lookups make you cross-reference two things; this returns them together.
• Field names don't move between runs. The output schema is frozen — registrar is always registrar, expiresAt is always expiresAt — so a Clay table or an agent's tool call built against it today still works against it next month.

What you get

One row per input domain. Every field below is present on a found: true row; on a miss, only query, found, status, message, and scrapedAt are set. Fields come straight from the registry's own RDAP response — nothing here is inferred, guessed, or backfilled from a second source.

Field	Type / format	Description
query	string	The domain exactly as you submitted it.
found	boolean	true if RDAP returned a registration record, false otherwise. Never charged when false.
status	string	OK on a hit; NOT_FOUND, BLOCKED, REQUEST_FAILED, or BAD_FORMAT on a miss.
domain	string	The domain name as returned by the registry (uppercased ASCII/LDH form, e.g. GOOGLE.COM).
registrar	string | null	The registrar's name, from the RDAP entity marked with the registrar role.
registrarIanaId	string | null	The registrar's IANA Registrar ID, from the registry's public-IDs list.
registrantOrg	string | null	Registrant organization (falls back to registrant name). Often null — most registrars redact this by default under GDPR and ICANN's Temporary Specification.
abuseEmail	string | null	The abuse-contact email listed against the registrar entity.
registeredAt	string (ISO 8601) | null	Registration date, from the RDAP registration event.
expiresAt	string (ISO 8601) | null	Expiry date, from the RDAP expiration event.
lastChangedAt	string (ISO 8601) | null	Last-modified date, from the RDAP last changed event.
domainStatus	array of strings	EPP status codes as reported by the registry (e.g. clientTransferProhibited). Named domainStatus, not status, because status is reserved for the row's own OK/NOT_FOUND state.
nameservers	array of strings	The domain's nameservers, in LDH form.
dnssecSigned	boolean | null	Whether the registry reports the domain as DNSSEC delegation-signed.
scrapedAt	string (ISO 8601)	Timestamp of the RDAP query for this row.
message	string (miss rows only)	Human-readable reason for a miss — e.g. no RDAP record found, or the request failed.

Price

$4 per 1,000 domains, plus a $0.005 start fee. Misses (found:false) are never charged.

That's the FREE-tier rate; it drops to $0.00304 per found row on the GOLD tier. 1,000 domains through this actor costs roughly $4 if every one is found, less if some aren't. The same 1,000 rows through a credit-based enrichment platform runs $80–$400 — this is one column, priced per column, not a seat-based workspace.

How to use

1. In the Apify Console. Open the actor page and click Start — the domains field is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found.
2. Via the API. Call it directly with a POST request — no Console needed once you have an API token:

   curl "https://api.apify.com/v2/acts/accountable_eel~domain-rdap-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"domains":["google.com"]}'
   

3. On a schedule. Save this actor as an Apify Task with the input you want, then add a Schedule (hourly, daily, weekly) so it runs on its own — no server of your own required.

1. Open the actor and paste your domains into the domains field, one per line — bare domains (google.com) or full URLs both work, since a leading http(s):// and any path are stripped automatically.
2. Leave maxConcurrency at its default unless you're running a very large batch; this target has no browser fallback, so a high concurrency on thousands of domains can trip rate limits on rdap.org's redirector.
3. Press Start. Each domain becomes one dataset row, tagged found: true or found: false.
4. Export the dataset as CSV/JSON, or pull it via the API — onlyFound and columns (see the integrations section below) let you trim the response before it lands in your table.
5. For expiry monitoring, save query and expiresAt somewhere durable and re-run the actor on a schedule — this actor doesn't retain state between runs, so the diffing (has this domain moved closer to expiry, has the registrar changed) is on your side, not the actor's.

A first run against a handful of domains you already know is the fastest way to see the field shapes before pointing this at a real list — registrantOrg and abuseEmail in particular are worth eyeballing once, since their presence varies a lot by registrar.

Input

{
  "domains": [
    "google.com"
  ]
}

One domain per line. A leading http(s):// and any path are stripped automatically, so a full URL works too. Accepted formats: google.com, example.org.

Sample output

query	found	status	domain	registrar	registrarIanaId	registrantOrg	abuseEmail	registeredAt	expiresAt	lastChangedAt	domainStatus	nameservers	dnssecSigned	scrapedAt
google.com	true	OK	GOOGLE.COM	MarkMonitor Inc.	292		abusecomplaints@markmonitor.com	1997-09-15T04:00:00Z	2028-09-14T04:00:00Z	2019-09-09T15:39:04Z	["client delete prohibited","client transfer prohibited","client update prohibited","server delete prohibited","server transfer prohibited","server update prohibited"]	["NS1.GOOGLE.COM","NS2.GOOGLE.COM","NS3.GOOGLE.COM","NS4.GOOGLE.COM"]	false	2026-08-26T06:00:53.669Z

A miss looks like: {"query": "some-unregistered-domain.com", "found": false, "status": "NOT_FOUND", "message": "No result was found for this input.", "scrapedAt": "2026-08-21T10:00:00.000Z"} — no charge, one row, same shape as a hit minus the RDAP fields.

Use it from Clay, n8n, Make, or an AI agent

This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.

curl "https://api.apify.com/v2/acts/accountable_eel~domain-rdap-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"domains":["google.com"]}'

n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~domain-rdap-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"domains":["google.com"]} (swap in an expression from an earlier node for a real value).

Clay. Add an "HTTP API" column: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~domain-rdap-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"domains":["{{domain}}"]}, mapping the row's domain into the domains array.

MCP. In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "Domain RDAP Lookup | Apify" — the agent will find and run this actor.

Tips

• Use columns to request only the fields you need (e.g. just expiresAt for an expiry-monitoring workflow) — it trims the response without changing what you're charged.
• Set onlyFound: true when you're piping straight into a Clay or n8n table and don't want to filter out miss rows downstream yourself.
• Keep maxConcurrency conservative (5 or below) on batches in the thousands — RDAP servers vary in how aggressively they rate-limit, and rdap.org's redirector is the single hop every request goes through.
• Don't expect registrantOrg to be populated for most domains — GDPR and ICANN's Temporary Specification mean it's redacted at the registry level for the large majority of registrations, corporate or not.
• Re-run periodically rather than caching the result yourself for expiry monitoring — expiresAt and domainStatus are live registry state and change without notice (a domain can enter a redemption-grace status before it actually drops).

vs. alternatives

For a one-off lookup, whois on the command line or a registrar's own web form is fine. This actor exists for the batch case — a list of domains in, a dataset of rows out, with the per-registry server resolution, retries, and rate-limit handling already done.

	What it costs	What you get	Trade-off
This actor (domain-rdap-lookup)	$0.004 per found row (FREE tier, $0.00304 on GOLD), $0.005 actor start, nothing for a miss	One flat row per domain — registrar, registration and expiry dates, nameservers, DNSSEC status, abuse contact, straight from the authoritative RDAP server	registrantOrg is redacted for most domains by the registries themselves, not by this actor, and coverage depends on the registry publishing an RDAP server — most gTLDs, a growing but incomplete set of ccTLDs.
Clay	$0.08–$0.40 per enriched row in credits, on top of a seat	A whole enrichment workspace — waterfalls across dozens of providers, plus the table and the sequencing around it	If you want one place that does everything and you're not counting rows, that's Clay. This is one column, priced per column, callable from Clay via its HTTP step.
Doing it yourself (whois / dig)	Your time — whois output is free-text that varies by registrar and TLD, legacy WHOIS servers rate-limit and time out, and some require querying a different server per TLD; dig gives you DNS records, not registration data	The same underlying registration facts, if you can find and parse them per registrar	This actor queries the same class of data through one structured JSON endpoint at $0.004 a domain, with the per-TLD server resolution, retries, and rate-limit handling already done.

Prices for third-party tools are their published list prices as of August 2026 and are not tracked here — check the vendor before relying on the comparison.

FAQ

What happens when a domain has no RDAP record? It still gets a row, with found: false, a status explaining why (NOT_FOUND, BLOCKED, REQUEST_FAILED, or BAD_FORMAT), and a message. You are never charged for that row.

Is this the same data as WHOIS? RDAP is ICANN's structured, JSON-based successor to legacy WHOIS — same underlying registration facts (registrar, dates, nameservers, status codes), returned as standardized JSON instead of free-text output that varies by registrar and requires per-TLD parsing.

Is this cached, or a live query every run? Live. Every row is a fresh RDAP request made when the actor runs — there's no local cache or stored snapshot from a previous run, which is why it's usable for expiry monitoring: expiresAt and domainStatus reflect what the registry says right now.

Why is registrantOrg blank so often? Since the EU's GDPR and ICANN's Temporary Specification, most registrars redact registrant personal and organizational details from public RDAP output by default. Some corporate-owned domains still expose an org name; most others won't. This actor returns whatever the registry publishes — it doesn't have access to redacted data.

Does this cover every TLD? Coverage depends on the domain's registry having a published RDAP server in IANA's bootstrap file. That's essentially all gTLDs (.com, .org, .net, and the rest) and a growing but incomplete set of ccTLDs. A ccTLD without an RDAP server comes back as found: false.

Are there rate limits I should worry about? The target has no browser fallback and goes through rdap.org's public redirector, so keep maxConcurrency moderate (5 or below) on large batches. Very large runs (tens of thousands of domains) benefit from splitting into smaller batches over time rather than maximizing concurrency. A domain that comes back BLOCKED after a burst of requests usually resolves itself on a retry a little later rather than needing a different approach.

Does this actor use a proxy? It queries rdap.org's public redirector directly rather than routing through a residential or datacenter proxy pool — RDAP is designed to be openly machine-queryable, so there's no anti-bot layer to route around, unlike a scraped web page.

Is this GDPR-compliant to use? Yes — this actor only reads what the registry itself publishes in its public RDAP response. It doesn't attempt to work around redaction; where a registry withholds registrant PII, registrantOrg simply comes back null.

Can I schedule this to run automatically, or call it from an AI agent? Yes to both. Set up an Apify schedule for recurring expiry monitoring, or call it via the Apify API from a script or n8n/Make workflow. It's also discoverable through the Apify MCP server, so an AI agent (Claude, Cursor, or any MCP client) can find and run it directly by name — see the integrations section above.

Related actors

• DNS Record Lookup — A, AAAA, MX, TXT, NS, and other DNS records for the same domains.
• Tech Stack Lookup — CMS, ecommerce platform, analytics, and other technologies detected on a domain.
• Email Deliverability Check — mail route, disposable-domain and role-address flags, and provider fingerprint for a domain.