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 24 hours.

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 24 hours.

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 24 hours.

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.

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 24 hours.

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.

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 24 hours.

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 24 hours.

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 24 hours.

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 24 hours.

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 24 hours.

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.

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. Cached for 24 hours.

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 24 hours.

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 24 hours.

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.

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.