canonical: https://jentic.com/apis/netlas.io/netlas

# Netlas API

Jentic publishes the only available OpenAPI specification for Netlas API, keeping it validated and agent-ready. Netlas API is an internet intelligence service that lets you query indexed data on hosts, IPs, domains, certificates, WHOIS records, and historical responses across the public internet. It exposes 42 endpoints covering host discovery, response search, certificate lookup, IP and domain WHOIS, and on-demand scanning. Use it for attack surface mapping, threat hunting, brand-protection investigations, and recon workflows that need to enumerate exposed services.

## For AI agents

Search internet-wide indexes of hosts, certificates, WHOIS, and responses to map external attack surface and investigate infrastructure.

## Scope

Does not handle vulnerability scanning with CVE matching, exploit delivery, or endpoint agent telemetry - use for internet-wide passive intelligence and discovery only.

## Capabilities

- Look up open ports, banners, and service metadata for any IPv4 host
- Search historical HTTP responses by header, body fragment, or technology fingerprint
- Resolve domain to current and historical WHOIS registration records
- Enumerate TLS certificates issued for a target domain or organisation
- Trigger on-demand scans against an IP range and pull structured results
- Pivot from a single artefact to related hosts, domains, and certificates

## Use cases

### External Attack Surface Mapping

Continuously enumerate every internet-facing host, certificate, and service tied to an organisation by pivoting from seed domains and IP ranges through Netlas indexes. Security teams use this to find shadow IT, expired certificates, and misconfigured services before attackers do. The host and certificate search endpoints return structured records that feed straight into a CMDB or ticketing flow.

Example prompt: Search Netlas for all hosts where ssl.cert.subject.common_name contains acme.com and return IP, port, and certificate expiry for each match.

### Threat Hunting and IOC Pivoting

Take an indicator of compromise such as a TLS certificate hash, JARM fingerprint, or HTTP response body string and pivot across Netlas indexes to find every other host sharing that artefact. Useful for tracking malware infrastructure, phishing kits, and red-team panels. Returns live and historical records so investigators can reconstruct campaign timelines.

Example prompt: Given a SHA256 certificate hash, query the Netlas certificates index and list every IP and port currently presenting that certificate.

### Brand and Domain Monitoring

Watch for newly registered or freshly indexed domains and certificates that match brand keywords or typo-squat patterns, then alert before a phishing site goes live. The WHOIS and certificate search endpoints support keyword and regex filters and return registration dates so monitoring can be scoped to a rolling window.

Example prompt: Search Netlas WHOIS for domains registered in the last 7 days containing 'acme' or 'acrne' and return the registrar and creation date.

### AI Agent Recon Assistant

Let an AI agent answer ad-hoc recon questions during an incident or pentest by translating natural-language asks into Netlas search queries through Jentic. The agent calls the right index endpoint, paginates results, and summarises findings without operators needing to learn Netlas query syntax.

Example prompt: Translate the user request 'show me Russian-hosted Cobalt Strike servers exposing port 50050' into a Netlas response search and return the top 20 IPs.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/api/host/{host}/` | Get full intelligence record for a host |
| GET | `/api/responses/` | Search indexed HTTP responses |
| GET | `/api/domains/` | Search the domain index |
| GET | `/api/whois_ip/` | Search IP WHOIS records |
| GET | `/api/whois_domains/` | Search domain WHOIS records |
| GET | `/api/certs/` | Search TLS certificates |

## Key resources

- **Hosts** — Search and inspect indexed internet hosts including ports, banners, and tech stack
- **Responses** — Query historical HTTP and HTTPS responses by header, body, or fingerprint
- **Domains** — Search domain index by name, subdomain, or DNS attributes
- **WHOIS** — Look up current and historical WHOIS records for IPs and domains
- **Certificates** — Search TLS certificates by issuer, subject, or fingerprint
- **Scanner** — Trigger on-demand scans against specified targets

## Why Jentic

- **Setup:** Wiring Netlas by hand means learning its bearer auth, targeting the app.netlas.io host, and constructing the query syntax for host, response, domain, and certificate searches yourself. Through Jentic you install once, import Netlas from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** Netlas puts the host in the URL path (`/api/host/{host}`/), so a rule can pin your agent to a single host lookup. You choose the operations it may call, so broad search endpoints like `/api/responses` are not included unless you add them.
- **Credential handling:** Your Netlas bearer token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'look up a host' or 'find WHOIS for a domain', and Jentic returns the matching Netlas operation with its query schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Shodan API** — Shodan is the longest-running internet scanning service and has broader IoT and ICS coverage; Netlas tends to ship richer historical response indexes.
- **Censys API** — Censys offers similar host and certificate search with an academic data heritage and strong BGP and ASN context.
- **AbuseIPDB API** — AbuseIPDB scores IPs by community-reported abuse history and pairs well with Netlas host data.
- **IP2Location.io API** — IP2Location.io enriches an IP with geo, ASN, and proxy attributes that complement Netlas host data.

## FAQ

### Why is there no official OpenAPI spec for Netlas API?

Netlas does not publish an OpenAPI specification on its own developer portal. Jentic generates and maintains this spec so that AI agents and developers can call Netlas API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Netlas API use?

Netlas API uses HTTP bearer token authentication. You pass your Netlas API key in the Authorization header as 'Bearer {key}'. Through Jentic the key is stored in the encrypted vault and never exposed to the agent context.

### Can I run on-demand scans of an IP range with the Netlas API?

Yes. The Scanner endpoints under `/api/scan`/ accept a target specification and return structured port and service results. Scan throughput is bounded by your Netlas plan.

### What are the rate limits for the Netlas API?

Rate and result limits are tied to your Netlas subscription tier rather than a fixed per-second cap. Free accounts get a small daily query budget; paid plans expose larger budgets and longer historical windows. Check your Netlas dashboard for current limits.

### How do I pivot from a certificate hash to live hosts through Jentic?

Run jentic.search('find hosts presenting a TLS certificate by SHA256'), load the resulting Netlas operation against `/api/responses`/ or the certificates index, and execute with your hash as the query parameter. The response returns IPs and ports currently serving that certificate.

### Does the Netlas API return historical data or only current state?

Both. Host, response, and WHOIS endpoints expose historical records with timestamps, so you can reconstruct how a domain or IP looked weeks or months ago. Use the date filters on each search endpoint to scope the window.

### Can I limit what my agent is allowed to do with the Netlas API?

Yes. Because you run Jentic One yourself, you decide which Netlas operations and credentials your agent may use. Since Netlas puts the target host in the URL path at `/api/host/{host}`/, your own rules can pin an agent to a single host lookup and leave broad search endpoints like `/api/responses` out unless you explicitly add them. Only the operations you allow are ever callable, so an agent built for host checks cannot reach certificate or WHOIS search on its own.