What an IP address tells you, field by field
Guarda answers three questions in one request: where the address is, who operates it, and how the connection is being made. That is the same ground covered by traditional geolocation databases, with the classification layer those products usually sell separately folded into the same JSON response.
Location
Where the address resolves geographically. Country-level results are reliable enough to enforce licensing and tax rules on; city-level results are best treated as a strong hint rather than a fact, because carriers route traffic through regional aggregation points that sit nowhere near the subscriber.
| country | Full country name of the allocation. |
|---|---|
| country_code | Two-letter ISO 3166-1 code, the field most rules key on. |
| region | State, province or administrative region. |
| state_code | Short administrative code where the registry publishes one. |
| city | Best-effort city for the allocation. |
| postal_code | Postal or ZIP code where available. |
| latitude / longitude | Approximate coordinates for the allocation, not the device. |
| timezone | IANA timezone identifier, useful for spotting activity at implausible local hours. |
| currency | Currency of the located country, handy for pricing and payment routing. |
Network
Who owns and operates the address. In fraud work the network is usually more informative than the location: the autonomous system tells you whether you are talking to a consumer broadband subscriber, a mobile carrier or a rack in a datacenter.
| asn | Autonomous system number announcing the prefix. |
|---|---|
| provider | Organisation behind the autonomous system. |
| isp | Internet service provider name. |
| domain | Primary domain associated with the operator. |
| hostname | Reverse DNS name, which often reveals the hosting product in use. |
| connection_type | Broadband, mobile, corporate or hosting-style connection. |
| cellular | True when the address belongs to a mobile carrier range. |
| ip_version | 4 or 6, so IPv6 traffic can be handled explicitly. |
Classification and risk
How the connection is being made. This is the part a pure geolocation database cannot answer, and it is what turns a location record into a decision.
| is_proxy | Any form of intermediary was detected. |
|---|---|
| proxy_type | The single most specific label: VPN, TOR, public proxy, web proxy or hosting. |
| tor / vpn / public_proxy / web_proxy | Individual anonymiser signals. |
| hosting | Address belongs to datacenter or cloud infrastructure. |
| residential | Address looks like an ordinary consumer connection. |
| search_bot | Verified crawler traffic, so you do not block your own indexing. |
| abuser | Address appears in abuse reporting. |
| risk | 0–100 score derived from the signals above. |
| risk_level | Low, medium, high or critical banding for simple rules. |
| risk_reasons | The specific reasons behind the score, so a decision can be explained. |
| confidence | How strongly the detection layer stands behind the verdict. |
How accurate is IP geolocation?
Country accuracy is high across every serious provider, because allocations are published by the regional internet registries and rarely ambiguous. Region and city accuracy degrade quickly, and no vendor that tells you otherwise is being honest with you. A mobile subscriber may appear hundreds of kilometres from their handset, a corporate VPN concentrator places every employee at head office, and satellite or rural links often resolve to the operator's peering city.
Design around that. Use country for compliance and tax decisions, use coordinates for soft signals like distance from a billing address, and never surface a city to an end user as though it were their verified location. Where precision genuinely matters, ask the browser for geolocation consent instead.
The network fields do not suffer the same problem. Whether an address sits in a datacenter, on a mobile carrier or on consumer broadband is a matter of ownership rather than estimation, which is why it carries most of the weight in our scoring.
Privacy by design
IP addresses are personal data under the GDPR, so the safest architecture is one where the vendor never keeps them. We do not write lookup results, queried addresses or per-request logs to any database — billing runs entirely on anonymous daily counters. Repeated lookups are served from a short-lived in-memory cache that is never persisted.