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 populated where the source data has coverage. 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 — we're honest about what we know

Geolocation is probabilistic. Here's how confident we are in each level of precision:

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

RIR delegation files refresh 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.
• 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": "[email protected]",
  ...
}

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.