Data sources

IP to Geolocation

Geolocation fields on every plan: country, country name, continent, region, city, latitude, and longitude — populated for every routable IP. Timezone and postal are not currently provided: both keys ship in the response for schema compatibility and are always empty. No field gating at any tier.

curl https://api.ip-atlas.io/json/8.8.8.8
{
  "ip": "8.8.8.8",
  "country": "US",
  "country_name": "United States",
  "continent_code": "NA",
  "region": "California",
  "city": "Mountain View",
  "latitude": 37.419,
  "longitude": -122.078,
  "postal": "",
  "timezone": ""
}

Accuracy — what we have measured

Geolocation is probabilistic. City, region and coordinates come from DB-IP's IP to City Lite database (IP Geolocation by DB-IP, CC BY 4.0). We measured the October 2026 build against RFC 8805 geofeeds — the location each network operator publishes for its own address space — on 9,552 sampled prefixes (2026-10-01):

These feeds cover cloud, satellite and privacy-relay networks, which are the hardest cases for IP geolocation. Privacy relays are built to hide where the user is. We have not measured residential broadband or mobile networks, so we do not publish a figure for them. On ground-truth university and registry blocks (UC Berkeley, Stanford, MIT, Oxford, University of Tokyo, RIPE NCC, APNIC, NIC.br), every lookup landed within 6 km of the real campus. Latitude and longitude are a city's centre point, never a street address. Region accuracy has not been measured separately.

Do not use IP geolocation as the sole basis for identity decisions. It is a probabilistic signal best combined with device fingerprinting, phone verification, and payment-method geography.

Update cadence

Every table is rebuilt daily at 06:00 UTC. Every IP-Atlas server picks up the new tables via a SIGHUP hot-swap — no restart, no dropped connections. You can verify the counts on our status page.

• IPv4 prefix table — full RIR rebuild every 24h.
• ASN → org table — full rebuild every 24h.
• City, region, coordinates — rebuilt every 24h from DB-IP's latest monthly release; the build in use is shown as city_source on /health.
• Datacenter / VPN lists — IP-Atlas-maintained, updated weekly.

ASN & Organisation

Every /json/* response carries an ASN and an organisation name, cross-referenced across all five Regional Internet Registries. 520,000+ ASNs catalogued; updated daily.

curl https://api.ip-atlas.io/json/1.1.1.1
{
  "asn": 13335,
  "org": "CLOUDFLARENET",
  "registry": "apnic",
  ...
}

How it's built

Every Regional Internet Registry (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) publishes daily delegated-extended files listing every allocated IPv4 prefix and every ASN. We reconcile all five into one authoritative table and then join against ARIN whois for organisation names. Rebuilt nightly, hot-swapped with a SIGHUP.

What you don't get

We don't currently return AS-path, BGP neighbours, or live route announcements. If you need real-time BGP, services like Team Cymru's Looking Glass or RIPEstat are the right tool. BGP live feed: contact us for enterprise integrations.

Privacy Detection (VPN / proxy / Tor / datacenter)

Every IP-Atlas response includes is_datacenter, is_vpn, and is_proxy booleans. Many providers gate these signals behind expensive paid tiers. We include them on every plan, including Free.

What we flag

Example

curl https://api.ip-atlas.io/json/8.8.8.8
{
  "ip": "8.8.8.8",
  "asn": 15169,
  "org": "GOOGLE",
  "is_datacenter": true,    // Google cloud range
  "is_vpn": false,
  "is_proxy": false    // trusted cloud allowlist
}

Why this matters

• Signup fraud. 70%+ of trial abuse originates from residential proxies and datacenter IPs. One boolean stops a lot of it.
• Scraping defence. Most scrapers rent VPS time — the ASN alone is a tell. Combine with per-IP rate limiting for hardened rate controls.
• Compliance. Some regulators (e.g. gambling commissions) require you to block VPN traffic from specific jurisdictions.
• Honest UX. A user on a VPN shouldn't be told "we detected unusual activity" with no way to verify themselves.

How it's built

Our datacenter list is a curated union of:

1. Official IP ranges published by each cloud provider (AWS ip-ranges.json, Google Cloud _cloud-netblocks.googleusercontent.com, Azure service tags, Cloudflare, etc.);
2. ASN-level matching for hosting networks that don't publish ranges (Hetzner, OVH, Vultr);
3. IP-Atlas-maintained edge cases for providers that move ranges frequently.

The VPN list combines the datacenter list with published VPN provider ASNs. We don't attempt to detect self-hosted VPNs or residential-proxy botnets in v1 — those need traffic analysis, not static ranges, and we're honest about saying so.

Coverage matrix

All privacy signals are available on the Free tier (2,000 req/month) — no upgrade required for production use of these fields.

Abuse Contact

Available now. Every API response includes the network's abuse contact email when published in RIR WHOIS. 246 ASNs (and growing) have curated abuse-contact mappings; everything else falls back to the registry-default contact.

Response shape

{
  "ip": "185.220.101.5",
  "asn": 205100,
  "org": "F3 Netze e.V.",
  "abuse_contact": "abuse@f3netze.de",
  ...
}

The field is present on every plan (including Free). We derive it from the same daily RIR feeds we use for ASN data, with fallback to the registry-default contact when a specific abuse address is missing.

Why surface it as an API field

• One less dependency. No embedded whois library, no separate TCP connection, no 43/tcp egress rules.
• Cached at our edge. Whois is rate-limited by registries; we cache the daily snapshot so your takedown job doesn't get throttled.
• Machine-readable. Parsed into a single RFC 5321 address string. No free-form text munging.

Typical use

1. Your SIEM flags suspicious scraping from a batch of IPs.
2. You POST /v1/batch those IPs to IP-Atlas.
3. For each result, you pull asn, org, and abuse_contact.
4. Your job templates a takedown email to the abuse contact. One job, 100 IPs, no whois dependency.

Every field above is on your free-tier response.