A domain age check answers a single factual question: when was this name first registered? The answer comes from the registry, so it is a date, not an estimate. What you do with that date is the harder part.
The domain age API returns the creation date and the age in years and days. With full=1 it adds the registrar, the nameservers, the status flags, the DNSSEC state and the days left before expiry.
curl -s "https://api2.globus.studio/v2/age?domain=example.com&full=1"What a domain age check returns
creation_date is the registry date in Y-m-d. age_years and age_days are derived, and expires_in_days is the number to watch on the operations side. A negative value means the domain is past its expiry date and may already be in a grace period.
The creation date is a fact about the name, not about the owner. A domain registered in 2004 can change hands next week, and the age stays. This is the reason the date is useful and the reason it is not proof of anything.
Five uses that hold up
A domain age check earns its place in these jobs:
- sorting a list of unknown senders before a human review, oldest first;
- adding context to a login alert from a domain registered last week;
- spotting a lookalike domain that copies a brand but appeared two months ago;
- monitoring a portfolio of domains you own, next to the expiry date;
- showing the date in a due diligence report, where the reader can weigh it.
Each use keeps a person in the loop. None of them rejects anything automatically.
The bad habit: age as a block rule
The common mistake is a rule like “block every domain younger than a year”. It catches every startup, every new product page and every acquired brand, and it misses every attacker who bought an aged domain on the aftermarket.
Age is easy to check, which makes it tempting to treat as a verdict. It is one field among many: WHOIS privacy, nameservers, certificate age and mail authentication say more about behaviour than the registration date does.
When the registry hides the creation date
Some registries and privacy services hide the creation date. A domain age check then returns an error instead of a guess, because “0 years” would read like a brand-new domain and send the reader in the wrong direction.
For zones without a WHOIS server, the record is read over RDAP, the HTTP protocol registries publish today. The fields and the date format stay the same, so a client does not need two parsers.
If the date is missing from every source, treat it as unknown in your report. An empty cell is honest, and a wrong date is worse than no date.
Keep the expiry date next to the age
The two dates answer different questions. Age says how long the name has existed; expires_in_days says how long it will keep existing. A domain that expires in ten days is an unpaid renewal, and the site, the mail and the certificate all fail together when it lapses.
Store the last successful domain age check next to the expiry date. A monitor that stopped running looks identical to a domain in good standing, right up to the moment it stops resolving.
Reading the response in code
The short response has four keys: domain, creation_date, age_years, age_days. Code that only needs the sort value should use that shape and skip full=1, which is slower because it parses more of the registry record.
A successful answer is cached for an hour by the service. Cache it on your side too, and never call the API inside a page render: a registry lookup behind a template is a timeout waiting to happen.
Related reading
The raw registry record, with fields this endpoint drops, is covered by the WHOIS lookup guide. For the certificate that usually expires with the domain, see checking a TLS certificate.
Further reading: RFC 7483, JSON Responses for RDAP and the ICANN lookup tool.