Atlas API

Full geolocation and network lookup for an IPv4 address, IPv6 address, or resolvable hostname. Returns country, continent, ASN, organisation name, and — as of v0.1 — the most-specific announced BGP prefix covering the IP. Cached for 7 days.

Returns all CIDR prefixes announced by an ASN, annotated with country and continent data. Now also includes pre-computed announcement size stats so consumers don't need to iterate the full prefix list. :as_number accepts a bare integer or an AS-prefixed string (e.g. 13335 or AS13335). Cached for 24 hours.

Search ASNs by multiple input types — automatically detected from the query string. Returns up to 25 matching { as_number, as_description } results.

Traceroute hop annotation — returns the reverse-DNS record, the ASN details, the internet exchange the address sits on if any, and a best-effort "PoP" (point of presence) match. An address inside a peering LAN is at that exchange by definition, so it places the hop outright; otherwise the PoP is derived from parsing the PTR against known carrier naming conventions (Hurricane Electric, Cogent, GTT, Zayo, Lumen/Level3, NTT). When no carrier pattern fits, a tier-2 "scatter" pass looks for 3-letter IATA hub codes and known city names anywhere in the hostname. Supports IPv4 and IPv6. Auto-generated IPv6 PTRs (e.g. residential Comcast nibble-hex labels) are detected and stripped before matching. Cached for 24 hours; rate-limited to 300 requests/minute per client IP.

Provenance for the topology dataset this instance is serving. Every other routing response embeds the same block, so a caller can always state what it is showing and when it was observed. Fetch this once to decide whether the routing endpoints are worth calling at all: 404 means no topology is loaded here, which is a normal state — a database image built before the routing tables existed, or a web image newer than its database image mid-rollout — and not an error. Cached for 1 hour.

Observed BGP topology for an autonomous system: the networks that carry its traffic, the networks it carries traffic for, and every AS seen adjacent to it in a routing path. Derived from bulk MRT routing tables (RouteViews route-views2 and RIPE RIS rrc00), which is the only way to answer "who provides transit to this network". Related networks come back named, joined in-database, so rendering a peering table costs one request rather than one lookup per row. Accepts 15169 or AS15169. Cached for 1 hour.

Everything here is an observation. These are AS_PATHs seen by a specific set of collector peers at a specific time, so every response embeds a snapshot block and callers are expected to show it. Two claims the data does not support: adjacency is not peering (two ASes next to each other in a path may be in a transit, settlement-free peering or customer relationship, and routing data cannot tell them apart, which is why the field is neighbours), and upstreams are inferred from the AS immediately preceding the origin, so for a tier-1 that buys transit from nobody it surfaces that network's peers instead. The response carries inferred: true so this cannot be missed.

How the internet actually reaches one address: every announcement covering it, most specific first, each with the AS originating it and how many collector peers saw that origin. This is strict BGP origin, which is a different and stricter question than "which ASN is this IP registered to" that /api/v2/ip/:ip answers. IPv4 and IPv6. Cached for 1 hour.

routed: false is a real answer, not a 404 — the address is allocated but not reachable, or announced only where our collectors cannot see. moas: true means the most specific prefix is announced by more than one AS: legitimate multi-homing or anycast, or a hijack. It is reported, never adjudicated. Note that two different prefixes covering one address is ordinary deaggregation and does not set moas. A leaked default route (0.0.0.0/0, ::/0) covers every address and is never listed.

Everything observed at, above and below one prefix: who originates it, which shorter announcements cover it, and what is announced inside it. IPv4 and IPv6; the slash can be sent literally or as %2F. Host bits are zeroed before lookup and the canonical form is echoed back, so 8.8.8.8/24 answers as 8.8.8.0/24 rather than as a miss. Cached for 1 hour.

routed: false is a real answer, not a 404 — nothing was seen announcing that exact prefix, though covering or more-specific routes may still be listed. More than one entry in origins is the same MOAS signal as on /api/v2/routing/ip/:ip: multi-homing, anycast or a hijack, reported, never adjudicated. A leaked default route covers everything and says nothing, so 0.0.0.0/0 and ::/0 are never listed as less-specifics.

Every row in origins, less_specifics and more_specifics.rows also carries its precomputed rpki_state, rpki_reason and irr_state, exactly as on /api/v2/routing/ip/:ip, so a prefix page needs no per-row RPKI or IRR lookups. A null state means that dataset is not loaded on this instance, never "bad".

The largest networks by one measure, from the same per-AS figures /api/v2/routing/asn/:as returns. Rows come back named, so a leaderboard is one request. Cached for 1 hour.

Every figure is what the collectors observed, not what a registry allocated: addresses counts IPv4 space seen announced, and upstreams / downstreams rank by the same inferred relationships as the per-AS endpoint, so a tier-1's upstream count is really its peers.

Registration and routing totals for every country that has at least one delegated AS number, largest IPv4 footprint first. Cached for 1 hour.

Country here is where the AS number is registered, not where the addresses are used. It comes from the RIRs' delegated statistics (the same data as the RDAP endpoints), and every prefix an AS originates is counted under that AS's registration country — a US-registered global CDN counts once, for the US, wherever its space is actually announced or used. Label it "registered in", never "located in". Registry pseudo-codes such as EU appear with name: null, because the registries really do file AS numbers under them.

Needs both the routing and the registry dataset: a 404 carries "no routing snapshot loaded" or "no registry dataset loaded" to say which is missing.

The routed networks registered in one country, largest IPv4 footprint first, with that country's totals row. :cc is a two-letter code, case-insensitive. The same registration-country caveat as /api/v2/routing/country applies: this lists networks whose AS number was delegated in the country, not networks that operate there. Cached for 1 hour.

A real country with nothing registered is a 200 with zeros, not a 404 — that is an answer. 404 "unknown country" means the code names no country at all: not two letters, or neither an ISO code nor present in any registry's statistics.

FBI IC3 malicious-IP reputation. Answers "is this IP listed in an FBI IC3 Cybersecurity Advisory (a 'flash')?" from the rolling last year of advisories at ic3.gov/CSA, alongside the geo/ASN summary — one call for where/whose an IP is and whether the FBI has named it. A clean IP returns 200 with ic3.listed = false (not 404). This is provenance, not a verdict: advisory IPs age and get reassigned, and advisories occasionally list victim/sinkhole IPs — weigh it as one signal, never a standalone block. Cached 24h.

A curated, plain-language "what is this network" TLDR for well-known ASNs — what it's used for, its location, and notable / interesting facts. Accepts 13335 or AS13335. AI-generated, best-effort context (see the disclaimer field): not authoritative and carries no guarantee of accuracy. body_markdown is a small markdown subset meant for client-side rendering. Only a curated set of ASNs has an entry — any other returns 404 (a normal answer, not an error). The source files are public and editable via source_url (the co-op repo). Cached 24h.

Provenance and licence for the internet-exchange dataset this instance is serving. Every other /api/v2/ix/* response embeds the same block. Fetch this once to decide whether the exchange endpoints are worth calling at all: 404 means no exchange data is loaded here, which is a normal state on a database image built before these tables existed, and not an error. Cached for 1 hour.

Attribution is required, not optional. The data is Packet Clearing House's, under CC BY-NC-SA 3.0: free to redistribute non-commercially, with attribution, under the same terms. That is why source and license are fields in the response rather than a footnote here — if you render this data, render those too.

The exchange directory, biggest first, optionally narrowed to a region and/or a country, with a region facet for building a picker. Every directory entry is included whatever its status — planned, deprecated and defunct exchanges too — so filter on that field if you only want live ones. Cached for 1 hour.

Attribution travels in snapshot. This is Packet Clearing House data under CC BY-NC-SA 3.0, exactly as described on /api/v2/ix/snapshot; render snapshot.source and snapshot.license wherever you render the list. members is what PCH has on file, not what is live, so a zero is not evidence of an empty exchange.

Find exchanges by name, city or country. Substring match across all three, with exact and prefix matches ordered first and dead exchanges last, so ?q=amsterdam and ?q=AMS-IX both put the obvious answer at the top. Returns the exchange summary only — call /api/v2/ix/:id for LANs and members. Cached for 1 hour.

Is this address sitting on a peering LAN, and whose port is it? This is the endpoint worth building on: a traceroute hop inside a peering LAN is at that exchange, which locates it far more reliably than an rDNS guess — the exchange's coordinates apply to the interface, not to the network that owns it. IPv4 and IPv6. Cached for 1 hour.

on_ix: false is the ordinary answer, not a 404 — most addresses are not on an exchange. ix.member names the network holding the port when Packet Clearing House has that exact address on file, and is null otherwise; it is an exact-address match, so there is no half-answer to misread. Deprecated LANs are matched deliberately — a hop on a retired peering LAN still crossed that exchange — and ix.prefix_status says so.

ix is singular, and sometimes that is one of two true answers. Packet Clearing House records a handful of fabrics under more than one exchange id — 206.72.210.0/23 is listed by both 373 and 2450, which are the same Los Angeles exchange — so also_recorded_as sits beside ix and names every other exchange whose active LAN also covers the address. It is [] for an unambiguous address, which is nearly all of them. ix itself is unchanged; nothing that worked before moves.

Anything covering the address counts here, not only an identical LAN: a carve-out registered by a different exchange is a competing claim on where the address lives, and that is precisely what the field exists to expose. Compare related on /api/v2/ix/:id, which asks the narrower question of whether two entries are the same fabric.

Every internet exchange a network is present on, with the address it holds there. One entry per exchange even for a dual-stack member on several ports. Pairs naturally with /api/v2/routing/asn/:as: that says who a network exchanges traffic with, this says where it does so. Accepts 15169 or AS15169. Cached for 24 hours.

An empty list is a real answer. Membership here is what Packet Clearing House has recorded, not what is live: roughly half the exchanges in the directory have no membership on file at all, and a network may also peer entirely privately. Absence is not evidence of absence.

One exchange in full: where it is, its peering LANs across both address families, and the networks on them. Members come back named and ordered by their own connectivity, joined in-database against the routing dataset — so rendering a members table costs one request rather than one lookup per row, and the default page is the networks worth naming. The :id is Packet Clearing House's own exchange id, which pch_url links back to. Cached for 1 hour.

Deprecated and defunct LANs are included with their own status, because a hop on a retired peering LAN still identifies the exchange it crossed. Filter on that field if you only want live ones.

One fabric is sometimes two directory entries. Packet Clearing House occasionally carries the same physical exchange under two ids, with nothing upstream linking them: 373 “Any2 California” and 2450 “Coresite - Any2 West” are both in Los Angeles, both advertise the identical active LANs 206.72.210.0/23 and 2001:504:13::/64, and 2450's 586 member addresses are a strict subset of 373's 718. related names the other entries. It is [] for 1,296 of the 1,327 exchanges in the directory, so treat a non-empty one as a signal, not noise: counting both ids as separate exchanges inflates any total you derive.

Matched on the peering LAN, never on the name. A peering LAN is one L2 broadcast domain, so two entries advertising the same active prefix are the same fabric — a fact about the network, not a guess. Names are the opposite of a signal here: “Any2 California” and “Coresite - Any2 West” share no words, while the genuinely separate Any2 metros (Denver, Chicago, New York, each on its own LAN) share plenty. Deprecated prefixes are excluded because a retired block can be reassigned, and the prefixes must be identical rather than overlapping, because a carve-out of a larger block is a different claim.

We cross-link, we do not merge. Merging would mean electing an authoritative record, which throws away the retired-LAN history only 373 carries, and every member port is recorded against a specific id, so rewriting it would lose provenance. Both records stay exactly as published and point at each other; deciding which one to show is yours. Relations are direct neighbours, not transitive clusters — exchange 712 shares an IPv4 LAN with 2402 and an IPv6 LAN with 2382, so it lists both while 2382 lists only 712.

Provenance for the registry-allocation dataset this instance is serving. Every other /api/v2/rdap/* response embeds the same block. Fetch this once to decide whether the registry endpoints are worth calling at all: 404 means no registry data is loaded here, which is a normal state on a database image built before these tables existed, and not an error. Cached for 1 hour.

Nothing here speaks RDAP. These endpoints answer the subset of questions an RDAP lookup is normally used for, out of a local table built from the five RIRs' daily delegated-extended statistics files. The point is that a consumer can stop making five third-party requests per page view.

Which registry holds this address, in which country, since when, and under what status. IPv4 or IPv6. Cached for 1 hour.

Read the fields_absent array before rendering. The delegated files carry no network name, organisation name or abuse contact, so those fields are not merely null here — they are not in the dataset. Rendering their absence as a fact about the network ("this network has no abuse contact") would be false. The array names them explicitly on every response so there is no need to guess.

Names come from two sources, and the response says which. whois is the registry object from the free bulk RPSL dumps of RIPE NCC, APNIC and AFRINIC, baked into this instance and always answered locally. ARIN and LACNIC publish no anonymous bulk dump, so their space is named only by detail, the lazily-filled RDAP cache (a cold address gets detail: null and a background fetch). netname is the convenience pick — bulk record first, RDAP cache second — with source naming which. fields_absent narrows to whatever is actually present; the bulk dumps never carry an abuse contact.

Two limits on the bulk record. It is the most specific object within what is loaded: end-user assignments smaller than /24 (IPv4) or /48 (IPv6) — some 5.4 million objects, mostly /29s — are left out, so an address inside one gets the covering LIR object instead. And placeholder objects every dump carries for space the registry does not manage (IANA-BLK over 0.0.0.0/0, APNIC's RIPE-CIDR-BLOCK over 193/8, and so on) are removed at build time by requiring both ends of an object to fall in one holder's delegation at the same registry.

status: "available" or "reserved" is a real answer, meaning the registries positively record that nobody holds this space. That is different from found: false, which means the address falls outside what the RIRs publish at all — IANA special-purpose space, roughly 14% of IPv4 (multicast 224/4, reserved 240/4, 0/8, 127/8 and friends). Both are 200s; a 404 is reserved for "no dataset loaded".

The registry record covering an entire CIDR block. Same response shape as /api/v2/rdap/ip/:ip, including netname and whois — where the bulk record, too, must contain the whole block. Cached for 1 hour.

This is not the same question as asking about the block's first address, and the difference bites. A block can span several allocations and be covered by none of them: 8.8.0.0/16 contains 12 separate registry records, so looking up 8.8.0.0 answers 8.8.8.0/22 with every appearance of confidence. This endpoint requires containment of the whole block and returns found: false when no single record covers it, which is the truthful answer.

Host bits are tolerated: 8.8.8.8/24 is read as the /24 containing that address.

The registry record covering an AS number. Accepts 15169 or AS15169. Cached for 1 hour.

Allocations are stored as closed ranges, so the response carries as_start and as_end rather than a single number — registries hand out 32-bit AS numbers in blocks, and the range is the record that actually exists. A single assignment simply has both ends equal.

Every other prefix and AS number the same holder has, taken from the opaque_id on any allocation response. This is the one field the delegated files give that RDAP cannot cheaply be asked for in bulk: it groups a registrant's resources without a name ever being involved. ?limit= caps each list (default 100, max 1000); the counts stay uncapped. Cached for 1 hour.

The registry is part of the key, not decoration. An opaque id is unique within one registry only — LACNIC publishes small integers, ARIN hex digests, RIPE UUIDs — and nothing coordinates them, so two registries can emit the same string for unrelated organisations. An endpoint keyed on the id alone would silently merge them, which is why this one will not accept it.

Provenance and global counts for the RPKI dataset this instance is serving. Every other /api/v2/rpki/* response embeds the same block. Fetch this once to decide whether the RPKI endpoints are worth calling at all: 404 means no RPKI data is loaded here, which is a normal state on a database image built without it, and not an error. Cached for 1 hour.

Validity is a statement about one snapshot. The VRPs are rpki-client's validated output as of generated_at, and the route states are RFC 6811 origin validation precomputed at build time for every announcement in the loaded routing snapshot — not re-evaluated per request. ROAs are issued and revoked continuously, so show the date beside any badge you render. not_found — no ROA covers the route — is the normal state for a large share of the table (about a quarter of it at the time of writing) and is not a fault.

RFC 6811 route-origin validation of any (prefix, origin) pair against the loaded VRP set — an announcement that exists or one you are only planning, which is what makes it useful for "would this be accepted?" before it is made. Evaluated live against the VRPs, unlike the precomputed states on the other RPKI endpoints. Cached for 1 hour.

valid: a covering VRP names this origin and allows this length. invalid: covered, but not valid — reason length when a VRP names the right origin but the route is more specific than its max_length, otherwise as (including routes covered only by an AS0 ROA, which authorises nobody). not-found: no VRP covers the prefix at all; that is the normal state for much of the table and not an error. An invalid is a mismatch with what the address holder published, not proof of a hijack — stale or overly tight ROAs are the usual cause.

Every VRP covering a prefix, whatever AS it names — "which ROAs govern this space, for whom, and how specific may they go", without guessing an origin for /api/v2/rpki/validate first. An empty list means no ROA covers the prefix, so any announcement of it is not-found. Cached for 1 hour.

A VRP naming AS 0 is an AS0 ROA: the holder is saying nobody may originate that space, so it invalidates any route it covers that no other VRP authorises.

Everything RPKI says about one AS: the precomputed state of each announcement it originates, the ROAs that name it, and its ASPA record. Accepts 13335 or AS13335. An AS that publishes nothing is a 200 with zeros and empty lists — "this network publishes no RPKI" is the answer, not a miss. Cached for 1 hour.

ASPA is new and rare — aspa: null means nothing. Only a few thousand networks have published an Autonomous System Provider Authorization at all, so its absence is not a misconfiguration and must not be rendered as one. When present, providers lists the upstreams the AS has authorised; a single provider of 0 is the AS declaring that it has no providers.

prefixes and roas.rows are each capped at limit (default and maximum 5,000); summary.total and roas.count are the true counts beside them, so truncation is always detectable. prefixes lists problems first — invalid, then not-found, then valid — so a cap never hides the routes that need attention. Note the spelling: the per-route state is not-found while the summary key is not_found.

Every RPKI-invalid announcement in the loaded routing snapshot, most widely seen first — the routes actually propagating despite failing validation rank highest, and the ones most networks already filter sink to the bottom. States are the build-time precompute described on /api/v2/rpki/snapshot. Cached for 1 hour.

An entry here is a mismatch, not an accusation. It means the announcement disagrees with the ROAs its address holder published at snapshot.generated_at; stale ROAs and traffic-engineering more-specifics beyond max_length are far more common causes than hijacks. That is why the list carries its snapshot.

Provenance and headline counts for the Internet Routing Registry dataset: route objects and as-sets from eight registries — RADB, RIPE, ARIN, APNIC, LACNIC, AFRINIC, ALTDB and NTTCOM. Every other /api/v2/irr/* response embeds the same block. 404 means no IRR data is loaded here, a normal state and not an error. Cached for 1 hour.

A route object is a claim, not an authorisation. IRR data is self-asserted: anyone with an account on a registry like RADB can register an object for any prefix. registered means an object exists — the thing IRR-based prefix filters are built from — not that the announcement is legitimate. RPKI is the dataset for that question.

Each observed announcement gets one precomputed state, first match wins: registered (an object with the same prefix and origin, in any registry) > covered (a less-specific object with the same origin) > mismatch (objects for the exact prefix, but only with other origins) > missing (none of those).

Route objects registered for a prefix: every object for the exact prefix in any registry, the less-specific objects covering it, and how many more-specific objects sit inside it. The prefix length is required (a bare address is a 400); host bits are zeroed and the canonical prefix echoed back. Empty lists are a real answer, not a 404. Cached for 24 hours.

Two objects for one prefix and origin in different registries — or objects for different origins — are normal: nothing reconciles the registries, and stale objects are rarely cleaned up. Show source, mnt_by and last_modified so a reader can judge each claim.

The IRR view of one origin AS: the precomputed state of every announcement it originates, every route object naming it as origin (flagged by whether it is actually announced), and the as-sets that list it directly. Accepts 13335 or AS13335. An AS with nothing registered is a 200 with zeros. Cached for 1 hour.

prefixes and route_objects.rows are capped at limit (default and maximum 5,000), as_sets at 5,000; summary.total, route_objects.count and as_sets_count are the true counts beside them. Large networks exceed these caps — AS13335 has over 56,000 route objects naming it — so both lists put problems first: prefixes runs mismatch, missing, covered, registered, and route_objects.rows lists objects that are not announced (often stale) before announced ones.

An as-set's objects in every registry that has one by that name, and its recursive expansion to AS numbers — the list a bgpq4-style filter would be built from. Names are case-insensitive and may be hierarchical (AS8283:AS-COLOCLUE); at least one component must be an AS- set name, so AS13335 or RS-FOO is a 400. Cached for 1 hour.

The expansion is bounded and says so. Real as-sets nest deeply and loop, so the walk stops at depth 6 below the root, 2,000 sets visited, or 50,000 ASNs, and sets truncated: true whenever any bound cut it short — the big transit sets hit these. Never present a truncated expansion as complete. Members are merged across every registry holding a set of that name, which is what bgpq4 does when pointed at all sources — but the same name in two registries can belong to two different operators, so check objects when that matters. Expansions are cached per server process, so repeat requests for a big set are cheap.

The bgpq4-style prefix list for an as-set: expand it exactly as /api/v2/irr/as-set/:name does (same bounds, same cache), then every distinct route / route6 prefix whose origin is in the expansion, IPv4 first then IPv6, each in address order. This is the list an IRR-based filter would accept for the set — self-asserted claims, not a statement of legitimacy. Cached for 1 hour.

truncated: true means the filter is incomplete — either the expansion hit a bound (asns.truncated) or limit cut the list (count is larger than the rows returned). Big transit sets run to millions of prefixes: AS-HURRICANE expands to 25,657 ASNs and 1.8 million distinct prefixes.

Which baked datasets the database behind this instance actually has: for each dataset, whether every table it needs is present, with approximate row counts, plus when Postgres last started and the database size. The snapshot endpoints report provenance; this reports presence. A dataset endpoint answering 503 "tables missing" points here. Never cached.

Returns the full country name as a plain text string. Ideal for shell pipelines. Accepts IPv4, IPv6, or any resolvable hostname. Cached for 7 days.

Returns the bare ASN number as plain text — no "AS" prefix.

Returns the full continent name as plain text.