Pattern search on issued.live finds domains by the shape of their names

issued.live pattern search matches a naming hypothesis against every registrable domain in its corpus, which held more than 454 million domains on September 25, 2026. Written as [a-z]{4,10}agent.com, the hypothesis "a short word followed by agent, in .com" returns the names that fit, each with its nameservers and certificate ID. The endpoint is GET https://issued.live/api/v1/search?name={pattern}, and it comes with the Pro plan at $199 a month.

A naming hypothesis has no wordlist to enumerate, and the space of candidates is combinatorial. The match therefore runs next to the data.

The grammar is written forward, one label at a time

Write the pattern the way you say the name. Each label takes four kinds of token:

Grouping, alternation and negation are unsupported. The response returns the compiled expression as regex, so you can see exactly what ran.

Every pattern names a TLD

A pattern must include a TLD label. *agent alone could mean a name or a suffix, and a guess would search the wrong one. *agent.* means every TLD.

Naming a specific TLD sets the cost of the query. issued.live stores names suffix-first, so a pattern that pins the TLD becomes a key range, and a pattern with a wildcard TLD reads the whole key space. The Pro API reference publishes these timings:

A literal start to the name lengthens the key prefix: loop-*.com anchors on com.loop-, while the counted class at the front of [a-z]{4,10}agent.com leaves only com.. The response reports anchored and key_prefix, so you can see which case you landed in.

Bounds on a pattern and a page

A character class needs a closed count with an upper bound of 64 or less. [a-z]+ and [a-z]{4,} are refused with 400 bad_request. The cap stops a pattern from silently becoming a full scan.

Filtering hits by nameserver

ns= matches a nameserver by exact name or by parent domain, so ns.cloudflare.com matches teresa.ns.cloudflare.com and every other nameserver beneath it.

The filter applies after the page is drawn. scanned reports how many candidates the page examined and count how many it returned, and the two differ when ns= removed rows. Keep following next_cursor until it is absent. The cursor advances over candidates, so a page that returns nothing still moves the walk forward.

The reference's pivot workflow runs a search with a nameserver filter, reading the key from an environment variable:

import os, requests

H   = {"Authorization": f"Bearer {os.environ['ISSUED_LIVE_KEY']}"}
api = "https://issued.live/api/v1"
get = lambda path, **kw: requests.get(f"{api}{path}", headers=H, timeout=30, **kw).json()

s = get("/search", params={"name": "loop-*.com", "ns": "ns.cloudflare.com", "limit": 500})
print(s["count"], "names match the grammar on that nameserver")

The reference rates a shared nameserver as a moderate link: "Strong when the pair is account-specific, weak when it is a large provider's default." A shared nameserver pair, a same-day registration and a name that fits the grammar together make a far stronger signal than any one of them alone.

Window mode searches the registration feed by date

Sending first_seen_from or first_seen_to switches the search to window mode. The date leads the sort key there, so the query becomes an index range, measured at 0.094 s. Window mode answers questions such as which names matching this grammar appeared last week. To keep a grammar current, rerun it in window mode with first_seen_from set to the time of the previous run.

Without a window the search runs in corpus mode over every name issued.live holds, paged by key. The mode field says which one ran. Sending only first_seen_to sets the lower bound to 30 days back, and the reply echoes the window it applied. Both bounds take RFC 3339, YYYY-MM-DD HH:MM:SS, YYYY-MM-DD or a Unix timestamp, and a reversed window is a 400.

A window cursor carries a position in time and a corpus cursor carries none. A cursor from the wrong mode gets a 400, so a walk cannot silently restart.

What the answer looks like

An example response for [a-z]{4,10}agent.com at a limit of 100:

{
  "pattern":    "[a-z]{4,10}agent.com",
  "regex":      "^com\\.[a-z]{4,10}agent$",
  "mode":       "corpus",
  "anchored":   true,
  "key_prefix": "com.",
  "count":      100,
  "scanned":    100,
  "limit":      100,
  "truncated":  true,
  "next_cursor": "H2NvbS5hYmJpbnNhZ2VudA",
  "domains": [
    {
      "domain":          "abbinsagent.com",
      "tld":             "com",
      "first_zone_seen": "2026-09-05T22:00:00Z",
      "first_cert_seen": "2026-09-06T04:21:09Z",
      "cert_id":         "b800bf9f6375b6825ca2b92d97bbb06f",
      "ns": ["ns1.zoom.ph", "ns2.zoom.ph"]
    }
  ]
}

regex shows the pattern compiled against the suffix-first key, starting at com.. first_zone_seen records when issued.live first saw the name in a zone file, and cert_id is the key for the certificate endpoint, /api/v1/cert/{cert_id}.

Certificate detail is live for 48 hours. After that, Pro answers from the archive: a lookup with no parameter searches the most recent seven archived days, and ?day=YYYY-MM-DD or ?from=&to= reaches further back, as far as September 9, 2026. An archive lookup takes seconds, and at most two run at once across all callers.

A search takes one of two concurrency slots

Pattern search is an advanced query, and Pro runs two advanced queries at once per account. Reverse IP, range, batch lookup and the provisioning feed take the same slots. Certificate, key, domain, timeline and newly registered domains lookups take none. Pro's 1,200 requests a minute meter the public record API, and the slots bound the advanced queries.

When both slots are busy, a request waits up to five seconds for one, then returns 503 timeout. The status is expected on unanchored searches. Retry once, then narrow the pattern. Branch on the retryable field and the Retry-After header.

Plan and documentation

Pattern search comes with Pro. Plus, at $99 a month, runs one advanced query at a time and has no pattern search. The pricing page compares the plans, the Pro API reference documents each parameter, and the paid plans announcement of September 19, 2026, introduced Basic, Plus and Pro.

Parameters, caps and measurements come from the issued.live Pro API reference, and plan details from the pricing page, both as read on September 25, 2026. More about the author.