# Domain RDAP Lookup — WHOIS Successor Registration API (`accountable_eel/domain-rdap-lookup`) Actor

Look up any domain's registration data via RDAP, the ICANN-standardized WHOIS successor — registrar, registration and expiry dates, nameservers, DNSSEC status, and abuse contact — straight from the registry's own RDAP server. No API key, no scraping. Charged per domain found; misses cost nothing.

- **URL**: https://apify.com/accountable\_eel/domain-rdap-lookup.md
- **Developed by:** [Adrian Voss](https://apify.com/accountable_eel) (community)
- **Categories:** Lead generation, Developer tools
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $3.04 / 1,000 successful lookups

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Domain RDAP Lookup

You give this actor a list of domains. For each one, it queries [RDAP](https://about.rdap.org) — the ICANN-mandated, standardized JSON replacement for WHOIS — through the public [rdap.org](https://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:
   ```bash
   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

```json
{
  "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.

```bash
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](https://apify.com/accountable_eel/dns-record-lookup) — A, AAAA, MX, TXT, NS, and other DNS records for the same domains.
- [Tech Stack Lookup](https://apify.com/accountable_eel/tech-stack-lookup) — CMS, ecommerce platform, analytics, and other technologies detected on a domain.
- [Email Deliverability Check](https://apify.com/accountable_eel/email-deliverability-check) — mail route, disposable-domain and role-address flags, and provider fingerprint for a domain.

# Actor input Schema

## `domains` (type: `array`):

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. You're only charged for the ones we actually find — a miss costs nothing.

## `testRun` (type: `boolean`):

Turn this on to test your input on a small sample before running the full list. Turn it off to process everything.

## `onlyFound` (type: `boolean`):

Only keep rows where something was actually found. Misses are always free, whether or not you show them here.

## `includeKeywords` (type: `array`):

Optional. Only keep results that mention at least one of these words (e.g. a job title, a city, a product name). Leave empty to keep everything.

## `excludeKeywords` (type: `array`):

Optional. Drop any result that mentions one of these words. Leave empty to skip nothing.

## `maxResults` (type: `integer`):

Optional. Stop the run once this many results have been found — useful for a quick, cheap sample. Leave blank for no limit.

## `columns` (type: `array`):

Choose which pieces of information to include in each result row. All are included by default.

## `maxConcurrency` (type: `integer`):

Parallel requests. Keep conservative — this target has no browser fallback, so getting blocked costs more than slow-and-steady.

## `proxyConfiguration` (type: `object`):

Apify Proxy config. Residential recommended for anti-bot-sensitive targets.

## Actor input object example

```json
{
  "domains": [
    "google.com"
  ],
  "testRun": false,
  "onlyFound": false,
  "includeKeywords": [],
  "excludeKeywords": [],
  "columns": [
    "domain",
    "registrar",
    "registrarIanaId",
    "registrantOrg",
    "abuseEmail",
    "registeredAt",
    "expiresAt",
    "lastChangedAt",
    "domainStatus",
    "nameservers",
    "dnssecSigned"
  ],
  "maxConcurrency": 5,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}
```

# Actor output Schema

## `results` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "domains": [
        "google.com"
    ],
    "includeKeywords": [],
    "excludeKeywords": []
};

// Run the Actor and wait for it to finish
const run = await client.actor("accountable_eel/domain-rdap-lookup").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "domains": ["google.com"],
    "includeKeywords": [],
    "excludeKeywords": [],
}

# Run the Actor and wait for it to finish
run = client.actor("accountable_eel/domain-rdap-lookup").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "domains": [
    "google.com"
  ],
  "includeKeywords": [],
  "excludeKeywords": []
}' |
apify call accountable_eel/domain-rdap-lookup --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,accountable_eel/domain-rdap-lookup"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/gOaE65C8bjmpKFvYF/builds/cMtl37Lc6fx1YN7ng/openapi.json