IP data is everything that can be learned about an IP address without talking to the device behind it: who holds the block, which network routes it, roughly where it is used, what kind of connection it is, and whether it has been seen misbehaving. The lookup dissected below came back with 76 fields. They do not deserve equal trust.
The AS number in a response is a fact read from the global routing table. The city is an estimate. The VPN flag is part observation and part guess, and either can be stale by next week. This post takes one real response, goes through it field by field, says where each value comes from, and rates how much weight it can bear.
Four layers of sources sit behind every IP lookup
The registry layer is the oldest. IANA hands address space to the five regional internet registries (ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC), which allocate it to ISPs and companies and publish the holder, the registration date and the contacts over WHOIS and RDAP. We count in the same layer whatever operators declare about their own space. The main case is geofeeds in the RFC 8805 format, discovered through the registry as RFC 9632 describes. Cloud providers, relay services and the Tor Project publish range files too, and if you want to see what one looks like, open the AWS range list, Apple’s Private Relay egress ranges or the Tor exit list. Those three are examples you can inspect, not an inventory of what we ingest. Declared files are one input among many, and most networks publish nothing at all.
The routing layer is BGP. It says which autonomous system originates which prefix right now, and RPKI says whether the holder authorized that origin. Nobody declares this for our benefit. It is simply how packets get there, which is why it is the most dependable layer of the four.
The measurement layer fills in what nobody declared. Light in fiber covers about 200 km per millisecond, so a 10 ms round trip from a known vantage point puts a host within 1,000 km of it, and several vantage points narrow that down. Router hostnames found through reverse DNS often embed an airport or city code, and traceroute shows which of those routers sits in front of an address.
The behavior layer is what an address has been seen doing: hitting honeypots, appearing in abuse reports, or turning up as the exit we were handed by a VPN or proxy service we subscribe to. It is the only layer that says anything about intent. It also goes stale faster than the other three.
Manual corrections sit on top of all four. Automated processing gets things wrong, so we also review correction requests sent by network operators, trusted sources and ordinary users, and apply the ones that hold up. A correction overrides whatever the layers concluded for that range. If you run the network, a geofeed is the better route, because it keeps correcting itself every time you update it.
A real response, annotated
Here is what api.ipregistry.co returned for 216.65.149.37 on September 20, 2026, trimmed to the fields discussed below, with keys sorted by name. The full response also carries country metadata (borders, languages, flag URLs, calling code) and currency formatting rules.
{
"carrier": { "mcc": null, "mnc": null, "name": null },
"company": {
"domain": "20point.net",
"name": "20 Point Networks LLC",
"type": "business"
},
"connection": {
"asn": 6079,
"domain": "rcn.com",
"is_anycast": false,
"organization": "RCN",
"route": "216.65.144.0/20",
"type": "isp"
},
"currency": { "code": "USD", "symbol": "$" },
"hostname": null,
"ip": "216.65.149.37",
"location": {
"city": "Washington",
"continent": { "code": "NA", "name": "North America" },
"country": { "code": "US", "name": "United States" },
"in_eu": false,
"latitude": 38.89503,
"longitude": -77.03654,
"postal": "20230",
"region": { "code": "US-DC", "name": "District of Columbia" }
},
"security": {
"is_abuser": false,
"is_anonymous": true,
"is_attacker": false,
"is_bogon": false,
"is_cloud_provider": false,
"is_proxy": true,
"is_relay": false,
"is_residential_proxy": false,
"is_threat": false,
"is_tor": false,
"is_tor_exit": false,
"is_vpn": false
},
"time_zone": {
"current_time": "2026-09-20T07:32:09-04:00",
"id": "America/New_York",
"in_daylight_saving": true,
"offset": -14400
},
"type": "IPv4"
} Connection fields are read from the routing table
connection.asn and connection.route say that AS6079 originates 216.65.144.0/20. You can check that against any route collector. RIPEstat shows the same origin, and a ROA with a maximum length of /20 makes the announcement RPKI-valid. This is the part of the response we would bet money on.
It is only wrong while the routing table itself is wrong, during a hijack or a leak, and then for minutes or hours. The Virtualizor incident in August was one such window.
connection.organization is the registered name of the AS holder, here RCN, the US cable operator that now trades as Astound Broadband. connection.type is a classification of that network (isp, hosting, business, education, government or inactive) and is a judgment call on our side, easy for a cable ISP and harder for a company that sells both broadband and colocation out of one AS.
Company fields are read from the registry, and they can disagree with connection
company.name is the holder of the address block, which is often a different party from the network announcing it. ARIN’s RDAP record lists 216.65.128.0/19 as a direct allocation to 20 Point Networks LLC, registered on March 15, 2021, with a postal address in El Segundo, California.
So the block belongs to a California company, a /20 out of it is announced by an East Coast cable operator, and the user is in Washington, DC. None of the three statements is a mistake. The same /19 also has ROAs naming AS1239 and AS7029 as permitted origins, which is what address space looks like when its holder spreads it across several networks. If you geolocate from WHOIS alone, you put this visitor roughly 3,700 km from where they are.
Company data has a second limit, and our own field reference is blunt about it: a startup renting desks from WeWork shows up as WeWork. Registries record whoever was assigned the block. They know nothing about tenants.
Location gets weaker with every level of detail
Country is the strongest location field because every layer votes on it: the registry record, the geofeed if there is one, the country the AS operates in, and latency. Region and city lean on geofeeds and measurement. Without a geofeed, a city is an estimate, unless someone who knows better has told us and the correction was accepted.
How good an estimate depends mostly on the access technology. The 2026 study “Lost in the Prefix” compared four commercial databases against 37,302 ground-truth observations and found median errors of 3 to 16 km on fixed broadband and 179 to 207 km on mobile, with fewer than 1 percent of observations in the wrong country. We covered the mechanics, CGNAT and centralized packet gateways, in a separate post.
latitude and longitude deserve the least trust of anything in the response. They are the center of an area, a city or a postal code, printed with five decimals that imply a precision they do not have. The cautionary tale is a farm near Potwin, Kansas, which MaxMind used for years as the default coordinates for “somewhere in the United States” until 600 million addresses pointed at it and the family living there sued in 2016.
One flag changes how to read the whole block. When connection.is_anycast is true, the address is announced from many sites at once and has no single location. We return Brisbane for 1.1.1.1, which is where APNIC, the block’s registered holder, has its offices, while your packets to it are answered by whichever Cloudflare site is nearest to you.
Carrier is null for most addresses, and useful when it is not
The carrier object is filled only for mobile networks. Look up 172.56.10.10 and it reads T-Mobile, MCC 310, MNC 260: the mobile country code and network code from the ITU’s E.212 numbering plan, the same pair a SIM card carries. A non-null carrier means the prefix is used for cellular traffic with very high likelihood.
Its real use is as a modifier on everything else. If carrier.name is set, stop trusting the city, expect many subscribers behind the address, and never block on a single bad event.
Security flags mix published lists, observation and inference
Some of these flags start from something the operator declares. is_bogon comes from IANA’s special-purpose registries and unallocated space, and is never ambiguous (more on bogons here). is_tor and is_tor_exit track the Tor network, whose relays are public by design. is_relay marks relay services such as Apple Private Relay, which pool many users behind shared egress addresses. is_cloud_provider is where published files stop being enough: the largest clouds maintain range files, most smaller hosts publish nothing, and those are identified from registry records, routing and our own detection. Where a declared source exists, the main error mode is the delay between a change and its ingestion. Where none exists, the flag is only as good as the detection behind it.
is_vpn, is_proxy and is_residential_proxy are another kind of claim. Very few VPN and proxy companies publish their exit addresses, so we find them the direct way: we hold real subscriptions to those services and record the addresses they hand out. That part is observation. No set of subscriptions sees every exit, so the rest is guessed, inferred from how an address and the range around it look and behave. A flag on its own does not say which of the two produced it.
The proxy flag is set on our example and is_residential_proxy is not. We have this address as a proxy exit in leased space, not as a node in a residential proxy network. The residential flag marks the other case, a home connection that relays other people’s traffic through a residential proxy network. That is the awkward one: the ISP reassigns the address and the next subscriber inherits the flag until it ages out. is_abuser and is_attacker decay the same way.
To be fair to these fields, they are the reason most people buy IP data at all. Use them as a score input. Blocking on one inferred boolean alone will cost you real customers.
is_anonymous and is_threat add no information of their own. The first is true when is_proxy, is_tor or is_vpn is, and the second when is_abuser or is_attacker is. is_relay and is_cloud_provider feed neither.
Time zone and currency inherit the location’s error
Neither is looked up by IP. time_zone.id is the IANA tz database zone that contains the estimated coordinates, and currency follows from the country through ISO 4217. Currency is therefore as good as the country field, which is very good. Time zone is as good as the region, and it only goes wrong where an estimate lands on the far side of a zone boundary, a real possibility for mobile users in the US, Russia or Brazil.
A trust rating for each field
The ratings below are ours. They describe the kind of evidence behind a field, which predicts how it fails. Outside the routing fields, a value can also be a manual correction, which is a person overriding the evidence for a specific range.
| Field | Main source | Rating | How it goes wrong |
|---|---|---|---|
connection.asn, route | BGP tables | Authoritative | Hijacks and leaks, for minutes to hours |
security.is_bogon | IANA and RIR registries | Authoritative | In practice it does not |
company.name, connection.organization | RIR records | Declared | Leased space, stale records, tenants hidden behind a provider |
is_tor, is_relay, is_cloud_provider | Operator declarations, plus our own detection where none exist | Declared and observed | Lag after a change; hosts that declare nothing |
carrier | Operator allocations, MCC/MNC plan | Declared | MVNOs and roaming traffic appear as the host network |
location.country | Registry, geofeeds, latency | Declared and measured | VPNs, roaming, satellite, anycast |
location.region | Geofeeds, measurement | Measured | Regional ISPs with one central gateway |
city, postal, latitude, longitude | Geofeeds, measurement | Measured | Mobile and CGNAT; coordinates are an area center |
time_zone, currency | Derived from location | Inherited | Wherever region or country is wrong |
is_vpn, is_proxy, is_residential_proxy | Real subscriptions to the services, plus inference | Observed and inferred | New exits missed; wrong guesses; flags outlive an address reassignment |
is_abuser, is_attacker | Honeypots, abuse feeds | Inferred | Shared addresses; one event tars many users |
What IP data cannot tell you
It cannot tell you who someone is. An address identifies a network attachment point, and only the ISP can tie it to a subscriber, from its own logs, normally under a court order. Behind carrier-grade NAT even the ISP needs more than the address: one public IPv4 address fronts many customers drawing from the 100.64.0.0/10 shared space, and separating them takes the source port and an exact timestamp. That is why RFC 6302 asks servers to log source ports. The default nginx and Apache log formats still leave them out.
It cannot give you a street address. No field in any IP database is a building, whatever the decimals suggest, and the Kansas farm is what happens when people act as if one were.
It also cannot see through a tunnel. A lookup describes the address that reached your server. For a VPN, a corporate proxy, Private Relay or a roaming phone whose traffic is routed back through its home network, that is the exit, and the person may be a continent away. The security flags exist to tell you when that is likely. They do not recover the real location.
How different teams use it
Fraud teams read the fields against each other more than one at a time. A card issued in France, used from a hosting connection with is_vpn set, is a different transaction from the same card on a French ISP with a carrier attached. Our carding post covers where those checks fit in a checkout flow.
SREs mostly want connection.asn. When traffic triples at 03:00, grouping the access log by AS answers “is this one network or the whole internet” in a single query, and connection.type separates a crawler farm in a data center from an ISP outage that is making real users retry.
Product teams use the fields that tolerate error. Country drives language and currency, and a wrong guess costs one click as long as you offer a selector. Do not hard-lock a user to the detected country.
Compliance is the use that demands the most honesty about confidence. Sanctions screening and state-level rules such as Utah’s SB 73 lean on region-level location and VPN detection, the two weaker parts of the response. Record the evidence you had at decision time.
Querying IP data with curl, an SDK or the batch endpoint
A single lookup is one GET request. The fields parameter filters the response down to what you will use, which matters more for payload size at volume than you might expect.
curl "https://api.ipregistry.co/216.65.149.37?key=YOUR_API_KEY&fields=connection,location.country.code,security" The client libraries wrap the same call. In Python:
from ipregistry import InMemoryCache, IpregistryClient
client = IpregistryClient("YOUR_API_KEY", cache=InMemoryCache(maxsize=2048, ttl=600))
data = client.lookup_ip("216.65.149.37").data
print(data.connection.asn, data.location.country.code, data.security.is_proxy) For log enrichment, use the batch endpoint: a POST with a JSON array of up to 1,024 addresses, billed at one credit per address plus one for the request. Deduplicate first. A day of access logs usually collapses to a small fraction of its line count in distinct addresses.
curl -X POST "https://api.ipregistry.co/?key=YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '["216.65.149.37", "172.56.10.10", "2606:4700:4700::1111"]' Cache with the trust table in mind. Registry and routing fields change on a scale of weeks, location on a scale of days, and inferred security flags within hours, so one TTL for the whole response is a compromise. The ten minutes in the Python example suits a login or checkout path where the flags matter; analytics that only reads country and ASN can keep entries for 24 hours. Key the cache on the address, and for IPv6 consider keying on the /64, since a single subscriber will rotate through many addresses inside it.
Every field discussed here comes back from one Ipregistry call, IPv4 or IPv6, and a value we cannot determine is returned as null. You can run your own addresses through it with 20,000 free lookups to get started.
Frequently asked questions
What is IP data?
IP data is the information that can be attached to an IP address without contacting the device that uses it. It covers the registered holder of the block, the autonomous system that routes it, an estimated location, the connection type, the mobile carrier when there is one, and security flags such as VPN, proxy, Tor or known abuser.
How accurate is the location in IP address data?
Country is right in the large majority of lookups. Accuracy drops with every step down. A 2026 study of four databases measured median errors of 3 to 16 km on fixed broadband and 179 to 207 km on mobile connections, while fewer than 1 percent of observations landed in the wrong country. Latitude and longitude describe an area, never a building.
Can an IP address identify a person or a street address?
No. An IP address identifies a network attachment point, and behind carrier-grade NAT one public address is shared by many subscribers at once. Only the ISP can map an address, a port and a timestamp to a customer, and it does so from its own logs, usually under a court order.
Where does IP address data come from?
From four kinds of sources. Registry records held by the five RIRs, plus files that operators publish such as geofeeds and cloud ranges. The BGP routing table and RPKI. Active measurement such as latency and reverse DNS. And observed behavior, collected by honeypots, abuse reports and real subscriptions to VPN and proxy services. Manual corrections submitted by operators and users are applied on top.
Keep users in the loop Ship release notes that get read. Try Noticeable