rdap.org Isn't an API — It's a Redirect. Here's How to Use It.

If you went looking for rdap.org's API documentation, this is probably why you couldn't find it: rdap.org does not return domain data. It returns a redirect.

curl -sI https://rdap.org/domain/google.com | grep -i location
# location: https://rdap.verisign.com/com/v1/domain/google.com

Ask it about google.com and it answers 302 Found, pointing you at Verisign's server — the registry that actually holds the record. rdap.org is not a data API you query; it is a bootstrap redirector that tells your client where to go. Once that clicks, everything about how to use it — and where it stops being enough — falls into place. Here is the whole thing.

What rdap.org actually is

There is no single RDAP server. Every registry runs its own, on its own hostname (and a few don't publish theirs at all). rdap.org solves the "which server do I ask?" problem by aggregating every known RDAP endpoint behind one hostname. You send it a query; it looks up the authoritative server and answers 302 with that server's URL in the Location header. Your HTTP client follows the redirect and gets the real response from the registry.

It is maintained by Gavin Brown, independently — in his words, "in my own time and at my own cost," and the code is on GitHub. It is genuinely useful and free, and for occasional lookups it is the fastest way to hit RDAP without writing any discovery logic yourself.

If you just want to eyeball one domain in a browser, there is also a human-facing front-end at client.rdap.org (client.rdap.org/?object=example.com&type=domain) that runs the same lookup and renders the result. The rdap.org redirect described here is the machine-facing half — the one you call from code.

The endpoints

rdap.org mirrors the standard RDAP path structure (RFC 9082), so the object type is the first path segment:

# Domains
curl -sIL https://rdap.org/domain/google.com | grep -iE '^HTTP|^location'
# HTTP/2 302
# location: https://rdap.verisign.com/com/v1/domain/google.com
# HTTP/1.1 200 OK

# IP addresses -> the right RIR
curl -sI https://rdap.org/ip/8.8.8.8 | grep -i location
# location: https://rdap.arin.net/registry/ip/8.8.8.8

# Autonomous systems
curl -sI https://rdap.org/autnum/15169 | grep -i location
# location: https://rdap.arin.net/registry/autnum/15169

nameserver and entity queries work the same way. In every case the answer is a redirect — the data itself comes from whichever registry server the Location points at.

Because it's a redirect, follow the redirect

The single most common mistake is not following the 302. A bare curl prints the redirect and stops; you have to pass -L:

# Wrong — you get the redirect, not the data:
curl -s https://rdap.org/domain/google.com
# (empty body, 302 status)

# Right — -L follows the Location to Verisign and returns the JSON:
curl -sL https://rdap.org/domain/google.com | jq '.ldhName'
# "GOOGLE.COM"

Every HTTP library has an equivalent (allow_redirects=True in Python requests, redirect: 'follow' in fetch, and so on — most default to following, but check). The redirect is also cross-origin, from rdap.org to the registry's host, which matters if you are calling it from a browser: rdap.org sets Access-Control-Allow-Origin: *, but the registry you land on may not.

What you get back — and what you don't

Because rdap.org just forwards you to the registry, the response is whatever that registry sends — raw, and different for every operator. That has consequences:

No normalization. Verisign spells a status client transfer prohibited; another registry may nest the registrar name three levels deep in a vcardArray. rdap.org does nothing to smooth this over — you parse each registry's dialect yourself.
No registrar follow-through. .com and .net are thin registries: the registry response gives you the sponsoring registrar and a rel: "related" link, but the fuller record lives on the registrar's own RDAP server. rdap.org points you at the registry; following that second hop is on you.
No authentication, no bulk, no query parameters. It is one object per request, unauthenticated. There is no batch endpoint and no ?follow convenience.

None of this is a flaw — rdap.org does exactly one job, discovery, and does it well. It just means the "API" you were looking for is really the registry's API, reached through a redirect.

The rate limit

rdap.org is protected at the Cloudflare edge, and the limit is low by design: 10 requests in 10 seconds. The 11th comes back 429:

for i in $(seq 1 12); do
  curl -s -o /dev/null -w '%{http_code} ' "https://rdap.org/domain/example$i.com"
done
# 302 302 302 302 302 302 302 302 302 302 429 429

curl -sI https://rdap.org/domain/example.com | grep -i retry-after
# retry-after: 9

That is fine for interactive, occasional lookups and unworkable for anything batch. The documentation notes that "higher limits can be obtained by supporting RDAP.org" — a reasonable ask for a service one person funds. But if you are looping over a list of domains, you will hit 429 almost immediately, and you need backoff and caching regardless.

Where rdap.org stops

Two gaps catch people out, because rdap.org returns the same 404 for both:

A 404 can mean "not registered" — or "I don't know this TLD." rdap.org can only redirect to servers it knows about, and its map has holes. .io, for instance, runs a perfectly good RDAP server that rdap.org cannot find, so it answers 404 even though the domain exists:
```
curl -s -o /dev/null -w '%{http_code}\n' https://rdap.org/domain/example.io
# 404 — but .io RDAP works fine; it's just a stealth server
```
That whole failure mode — working servers rdap.org can't see — is covered here. Treating its 404 as "domain available" is a real bug.
The rate limit is the ceiling. For a personal script, 10-in-10 is invisible. For a product feature, it is a wall.

When rdap.org is enough — and when it isn't

For a one-off lookup, debugging, or a low-volume script, rdap.org is the right tool: free, no key, no discovery code. Use it and support it.

When you are building on RDAP — checking domains in volume, needing one consistent JSON shape across every TLD, following thin-registry referrals, reaching the servers rdap.org can't, and not babysitting a shared rate limit — that is where a managed API earns its place. RDAP API does the same discovery rdap.org does, then goes further: it follows the redirect and the registrar referral for you, normalizes every registry's dialect into one schema, covers the stealth TLDs, and gives you a per-account rate limit instead of a shared 10-in-10.

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://rdapapi.io/api/v1/domain/google.com?follow=true"

One authenticated request, redirect and referral already followed, flat normalized JSON. See the API docs for the schema. But for kicking the tires on RDAP from your terminal, keep rdap.org bookmarked — it is the cleanest front door the protocol has.