API

No key, no account, no cost. Be reasonable and it will stay that way. Every endpoint is a plain GET.

Plain text

GET /txt/{domain}?dates=1

One hostname per line, in name order, streamed — there is no page limit, so a domain with a hundred thousand names returns all of them in one request. This is the endpoint to pipe into other tools. It does not offer date order: streaming means never holding the whole result, and sorting by date would mean exactly that.

curl -s https://crt.live/txt/example.com | httpx -silent

dates=1 adds the first-seen day as a second, tab-separated column. It is off by default so the output stays pipeable.

www.example.com	2024-11-03
*.cdn.example.com	2025-06-18

JSON

GET /api/v1/domain/{domain}?sort={recent|name}&limit={n}&filter={substring}

Newest first by default. Names are stored in name order, so sorting by date means reading a domain's whole range and sorting it; that is free for an ordinary domain and too slow for the handful of cloud providers with millions of names, which fall back to name order with sort_downgraded set in the response.

The two orders paginate differently, because only one of them has an index behind it. sort=name is cursor paginated: pass the next value back as after, and page five thousand costs what page one does. sort=recent is offset paginated: pass next_offset back as offset.

{
  "apex": "example.com",
  "count": 2,
  "total": 2,
  "total_capped": false,
  "names": [
    {"name": "example.com",     "first_seen": "2024-11-03"},
    {"name": "www.example.com", "first_seen": "2025-06-18"}
  ],
  "next": "www",
  "has_more": false
}

Parameter	Default	Meaning
`sort`	`recent`	`recent` newest first, `name` alphabetical.
`after`	—	`sort=name` only: cursor from a previous response's `next`.
`offset`	0	`sort=recent` only: from a previous response's `next_offset`.
`limit`	100	Names per page, up to 10000.
`filter`	—	Only names whose subdomain part contains this substring.
`names_only`	0	`1` returns `names` as a plain array of strings, without dates.

Service

GET /api/v1/stats
GET /api/v1/logs

What is indexed

Every dNSName in the subject alternative name extension, plus the subject common name, of every certificate and precertificate in every Certificate Transparency log that Chrome or Apple currently consider usable.

Names are grouped by registrable domain, using the ICANN section of the Public Suffix List only. That means customer.herokuapp.com is filed under herokuapp.com, not treated as its own apex — so searching a hosting provider returns what is actually hosted there.

First seen

Each name carries the day it was first observed. The date comes from the Certificate Transparency entry itself — when the log recorded that certificate — not from when this service happened to read it, so it means the same thing however long the backfill takes.

It is the earliest sighting this service has made, which is not always the earliest that exists. While the historical backfill is still running, a name that first turns up on a certificate issued today will be dated today even if an older certificate for it is still waiting further back in a log. Dates only settle once backfill is complete.

Resolution is one day, deliberately. Nothing here can honestly claim more, and a date costs a third of what a timestamp would across billions of rows.

What is not

Nothing about the certificates themselves. No issuers, serials, validity dates, keys or fingerprints are stored, and there is no way to ask this service for them. It answers exactly one question: which hostnames have been seen under a domain.

A name here is a certificate observation, not proof a host exists, resolves, or ever did. Expired and revoked certificates are not distinguished, because the dates are not kept.

This is a monitor, not an auditor: log signatures and Merkle consistency proofs are not verified. HTTPS to the logs is.

Limits

120 requests per minute per address, and 10 per minute for /txt/. A 429 means slow down; the Retry-After header says by how much.