What IP geolocation and ASN lookup actually mean in 2026
IP geolocation resolves an IP address to a country, region, city, approximate coordinates, and timezone. ASN lookup resolves that same address — or an Autonomous System Number directly — to the network operator that owns it. Together they turn a raw IP into two answers most teams need: where the address sits, and who runs the network behind it. In 2026, the practical way to do this at scale is a managed API that returns clean JSON in a single call, single or bulk.
That paragraph is the short answer. The rest of this page is for the engineers and product leaders who have to actually wire it into a fraud check, an analytics pipeline, or a routing decision. We will name the use cases honestly, walk the recipe end to end with real commands, and flag where IP data lies to you so your pipeline does not.
The problem you are actually trying to solve
Nobody wants IP geolocation for its own sake. They want a decision. The reader of this page usually falls into one of three buckets, and the shape of the answer is different for each.
The first is a fraud and risk team. A signup, a checkout, or a login arrives with an IP attached, and you need a fast, cheap signal: what country is this, and is the address coming from a residential ISP or a datacenter? A datacenter or hosting ASN behind a consumer-facing signup is a classic risk signal — not a verdict on its own, but a strong input to a score.
The second is an analytics team doing geo-enrichment. You have a firehose of events or log lines, each with a source IP, and you want to roll up traffic by country and region, or attribute usage to a network. This is a bulk problem: thousands of IPs at a time, enriched and dropped into a warehouse.
The third is an infrastructure or routing team. You are deciding which region to serve a request from, which IPs to allow or deny, or auditing a claim that a block of addresses belongs to a particular operator. Here the ASN and its routed prefixes matter more than the city.
All three share a hidden requirement: the lookup has to be quiet, fast, and predictable. It should return a JSON record per IP, cost a known amount, and never block the request path it sits in. That is the actual product.
What this data is — and what it is not
Be honest with yourself about the data before you build on it. Ollagraph's intelligence endpoints run against local, open geolocation and routing databases. There is no outbound network call for these lookups — the IP is a key into a database read, not a page to fetch. That is why they are fast and why they carry no SSRF or abuse surface.
It also means this is free-data geolocation, not paid threat-intelligence. You are getting location and network ownership: where the address registers and who operates it. You are not getting a commercial threat feed, a breach database, or a reputation verdict rented from a third party. For the large majority of fraud and analytics pipelines, the location-and-ownership layer is exactly what you need first, and it is the layer you can run on every request without a per-lookup vendor bill.
The accuracy ceiling matters too. IP geolocation is dependable at the country level, usually good at region and city, and approximate at coordinates. It tells you where the network registers the address, not where a human is sitting. Treat city and coordinates as hints, treat country and ASN as signals, and you will not build a brittle pipeline on top of a noisy field.
The recipe, step by step
Here is the working playbook. Real curl commands, real request shapes. Drop these into a shell or your tool of choice and you have the building blocks of an enrichment pipeline. Every request example below points at the live API; the exact response fields are documented in the docs and the live spec.
Step 1. Get an API key
Sign up on the pricing page, grab an API key from the dashboard, and export it for the rest of this session. The key authenticates every call.
export OLLAGRAPH_API_KEY="osk_xxxxxxxxxxxx"Step 2. Geolocate a single IP
Start with one address to verify the flow end to end. The geolocation endpoint takes a single ip field and returns the full enrichment — country, region, city, approximate coordinates, timezone, and the network identity attached to the address.
curl -X POST https://api.ollagraph.com/v1/intel/geoip \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"ip": "8.8.8.8"
}'The response is a clean JSON object with the location and network fields for that address. Country and timezone are the reliable fields; treat city and coordinates as approximate. The network identity in the response — operator name and ASN — is the bridge to the ownership lookups in the next steps.
Step 3. Look up the network owner by ASN
Once you have an ASN from a geolocation lookup, you can resolve it to the operator name and every CIDR prefix that network announces. The ASN endpoint takes an asn field — an integer, without the AS prefix. For example, 15169 is one of Google's networks.
curl -X POST https://api.ollagraph.com/v1/intel/asn \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"asn": 15169
}'This is the call you use to compile per-network allow or deny lists, to map a customer's infrastructure across all the address blocks they announce, or to audit a claim that a given range belongs to a particular operator. Because it returns the routed prefixes, you can expand a single ASN into the full set of CIDRs it covers and match incoming IPs against them.
Step 4. Confirm the network type with reverse DNS
For the classic fraud question — "is this a datacenter IP or a residential ISP?" — reverse DNS is the cheapest tiebreaker. It resolves the IP back to its PTR hostname, which often names the operator directly. The endpoint takes a single ip field.
curl -X POST https://api.ollagraph.com/v1/intel/reverse-dns \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"ip": "1.1.1.1"
}'Not every IP has a PTR record configured, so treat the hostname as nullable and fall back to the ASN signal when it is absent. A hostname that names a known cloud provider, paired with a hosting ASN, is a strong "this is datacenter traffic" signal for a risk score.
Step 5. Scale up with bulk geolocation
One IP is a test. A real enrichment pipeline runs thousands. The bulk endpoint accepts a list of up to 100 IPs per call in the ips field and returns the same full enrichment for each one. Most teams chunk their IP set into batches of 100 and fan the calls out from a worker pool.
curl -X POST https://api.ollagraph.com/v1/intel/geoip/bulk \
-H "Authorization: Bearer $OLLAGRAPH_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"ips": [
"8.8.8.8",
"1.1.1.1",
"208.67.222.222"
]
}'Each IP in the batch is billed as one call, so the cost of enriching a log file is simply the number of distinct IPs in it. Deduplicate before you send — most event streams hit the same handful of addresses repeatedly, and caching the result for an IP for a day or two cuts the volume dramatically without losing meaningful accuracy.
Step 6. Land it in your warehouse
The last step decides whether the pipeline pays for itself. Store each enriched record with the source IP, an enriched_at timestamp, and the raw response in a JSON column so you can re-extract fields later without re-querying. Key your geo cache on the IP and a coarse expiry — a day is plenty for most fraud and analytics use cases — and you turn a per-event lookup into a fixed, bounded cost.
A realistic scenario
Consider a fintech onboarding team. Every signup arrives with a source IP, and the risk model needs three inputs from it within the request budget: the country, whether the address is residential or datacenter, and the network operator. The team does not want to rent a per-lookup threat feed for a signal this basic, and they cannot afford a slow external call in the signup path.
The pattern that works is a single geolocation call at signup, cached for the session, that yields country and ASN. The country drives a coarse risk band; the ASN is matched against a precompiled set of hosting and datacenter ASNs — built once with the ASN endpoint — to set a "datacenter origin" flag. When the flag fires and the stakes are high, a reverse-DNS call confirms the hostname before the score escalates. Three cheap, local-database lookups, no per-event vendor bill, and a risk signal that is good enough to gate the genuinely suspicious signups for human review.
An analytics team runs the same primitives differently. Instead of one IP at a time in the request path, they batch the day's distinct source IPs into chunks of 100 against the bulk endpoint overnight, join the country and operator fields back onto their event table, and power a "traffic by country and network" dashboard. Same data, batch shape, predictable nightly cost.
What can go wrong, and how to handle it
A few failure modes are worth planning for. Private and reserved IPs — anything in the RFC 1918 ranges, loopback, or link-local space — are not publicly routable and will not geolocate meaningfully. Filter them out before you send, or treat a non-result as "internal traffic" rather than an error.
Missing PTR records are normal, not a bug. Plenty of perfectly legitimate IPs have no reverse DNS configured. Lean on the ASN signal as your primary network-type input and use reverse DNS as confirmation, not as the sole determinant.
City and coordinate drift is the most common way teams get burned. Because the data reflects network registration, a national ISP can register a large block in one city while serving customers across the country. Build country-level and ASN-level logic; reserve city and coordinates for soft hints and visualizations, never for hard decisions.
Finally, if a lookup genuinely cannot be served, the API returns a structured error and the call is auto-refunded — you are not charged for a failure, and your pipeline should branch on the error rather than writing a null record as if it were a real result.
Where this fits in the wider stack
IP geolocation and ASN lookup are the entry point to Ollagraph's broader intelligence surface. The same local-database philosophy — fast, free-data, no abuse surface — runs through the rest of the intel endpoints, which is why teams building fraud and analytics pipelines tend to adopt several of them together. The intelligence use-case page walks through how risk and OSINT teams compose these primitives into a working enrichment layer.
If your enrichment also needs to watch certificates and subdomains for the networks you care about, pair this recipe with SSL and subdomain monitoring. And because every metered call exposes its own cost and outcome, the per-IP economics stay legible end to end — see the observability page for how each call is logged at the URL and request level. Browse the full capability surface when you are ready to compose a larger pipeline.
What to do next
Grab a key, paste the Step 2 command, and confirm you can geolocate a real IP in the next five minutes. Then pick one use case — a datacenter-origin flag in your signup flow, or a nightly traffic-by-country rollup — and wire the bulk endpoint into it. Most teams have a working internal enrichment job inside a week.
Read the docs, explore the intelligence endpoints, and ship something.