Subdomain Discovery API

Paginated subdomain enumeration for any registered domain — DNS records, registrar, WHOIS, vendor reputation, and category labels per subdomain.

API Overview

Subdomain Discovery API answers a single, high-value question: "What does this domain's attack surface actually look like?"

Send a registered domain — example.com — and get back the discovered subdomains along with the per-subdomain context you need to triage exposure: DNS records, registrar, WHOIS, popularity ranks, vendor reputation stats, tags, and category labels.

What you get on every request

• subdomains — an array of per-subdomain objects, each with:
  • subdomain — the FQDN (e.g. staging-api.example.com).
  • dns_records — A / AAAA / CNAME / MX records with TTLs.
  • registrar, whois — registrar string and the raw WHOIS block.
  • popularity_ranks — Alexa / Cisco Umbrella / Cloudflare Radar / Majestic ranks where available.
  • reputation, security_vendor_analysis_stats — vendor verdict tally so you can spot the subdomain that flipped malicious without re-enriching.
  • tags, categories, tld, modification_date, dns_records_update_date.
• cursor — opaque pagination token. Pass it back as the cursor query parameter to fetch the next page. Empty / missing cursor means "no more results".

Page size is fixed at 10 subdomains per request.

Pagination pattern

1. First request: GET /scan?query=example.com — returns the first 10 subdomains plus a cursor.
2. Subsequent requests: GET /scan?query=example.com&cursor=<cursor> — returns the next 10 subdomains plus the next cursor.
3. Stop when the response carries no cursor (or an empty one).

Cursors are tied to the query they were issued for — do not mix cursors across different domains.

What can you do with this API?

• 🎯 Attack surface in one call — no juggling between DNS, WHOIS, and reputation APIs. One request, full per-subdomain context.
• 🧠 Reputation built in — every subdomain already comes with security_vendor_analysis_stats, so you can flag a leaked staging subdomain on the first pass.
• 📚 Cursor pagination — bounded payloads, simple to integrate into any ASM crawl pipeline.
• 🔒 Battle-tested — used in production by ASM platforms, pentest teams, and bug-bounty hunters.

Response model

Every successful request returns:

{
  "is_success": true,
  "response_code": 200,
  "message": "Success",
  "data": {
    "search_type": "domain",
    "subdomains": [
      {
        "subdomain": "staging-api.example.com",
        "tld": "com",
        "registrar": "MarkMonitor Inc.",
        "dns_records": [{ "type": "A", "value": "1.2.3.4", "ttl": 300 }],
        "security_vendor_analysis_stats": { "harmless": 0, "malicious": 0, "undetected": 91 }
      }
    ],
    "cursor": "eyJsaW1pdCI6IDEwLCAib2Zmc2V0IjogMTB9"
  }
}

Always inspect is_success rather than relying on the HTTP status — invalid inputs and lookup misses are also returned with HTTP 200 and is_success: false.

Use cases

• Attack surface management (ASM) — continuously enumerate an organisation's external footprint and flag staging / preproduction / forgotten subdomains.
• Penetration testing reconnaissance — fast pivot from a single domain to the full subdomain inventory.
• Subdomain takeover detection — surface dangling subdomains pointing at unclaimed cloud resources.
• Brand protection — catch lookalike subdomains and verify ownership.
• Bug bounty scoping — quickly understand what targets are in scope.

How is this different from IoC Lookup / IoC Enrichment?

Subdomain Discovery takes one domain and returns its subdomains. IoC Lookup takes one indicator and returns reputation + vendor verdicts. IoC Enrichment takes one indicator and returns OSINT context (adversary, malware family, MITRE ATT&CK). They are complementary — discovery finds the subdomains, then enrichment / lookup tells you which matter.

Need something custom or need support?

Looking for bulk / streaming / on-prem, a different response format, or help with setup? Send us a DM and we'll be happy to help you find the best setup for your use case.