One dataset, one call
Location, ASN, connection type and anonymiser classification arrive together. There is no second lookup against a proxy database and no code to merge two records that occasionally disagree.
An IP2Location alternative without the BIN files
IP2Location's model is a licensed database you bundle with your application, split across numbered packages, plus a separate IP2Proxy product for anonymiser detection. It works, but it means shipping a multi-hundred-megabyte artifact with every release, tracking which package tier contains which columns, and reconciling two datasets to answer one question. Guarda replaces all of that with a single live endpoint that returns location, network and proxy intelligence together.
Who should consider switching
- Teams bundling BIN database files into container images or application releases.
- Anyone maintaining separate IP2Location and IP2Proxy datasets and joining them at runtime.
- Products where a package tier is blocking access to a field you need, such as connection type or usage type.
- Serverless and edge deployments where a large local database is impractical to load.
- Teams that want the queried address to leave no trace in the vendor's storage.
Where Guarda works differently from IP2Location
No package tiers gating fields
Every plan returns the complete field set — city, postal code, coordinates, timezone, currency, ASN, ISP, domain, hostname, connection type and the full proxy verdict. Plans differ by monthly query volume, not by which columns you are allowed to read.
Always current, never bundled
Data freshness is our problem, not a monthly download you have to schedule, validate and redeploy. Newly allocated cloud ranges are classified as hosting without you shipping anything.
Explainable verdicts
Instead of a set of independent boolean columns you have to interpret yourself, you get a single classification — VPN, TOR, public proxy, web proxy, hosting, residential or clean — with a risk score and the reasons that produced it.
No result retention
Lookup results and queried addresses are never written to our database. We keep anonymous daily query counters for billing and nothing more.
Data you get on every lookup
Country, country code and region
State code, city and postal code
Latitude, longitude and timezone
Currency of the located country
ASN, ISP and organisation
Domain and reverse hostname
Connection type and cellular flag
Proxy, VPN, TOR and web proxy detection
Hosting, datacenter and residential classification
Risk score, level and contributing reasons
Being straight with you
A local BIN database has one genuine advantage we cannot match: lookups with zero network latency and zero per-query cost, which matters if you are enriching billions of log lines offline or running in an environment with no outbound internet access. IP2Location also publishes some specialised datasets we do not, and their one-off perpetual licences suit organisations that prefer capital purchases to subscriptions. If offline enrichment at extreme volume is your workload, keep the database.
How a migration usually goes
1.Inventory the columns you read
Open the code that queries the BIN file and list the columns it actually uses. In practice it is usually country, city, ISP and the proxy flags — all of which map directly onto Guarda's response fields.
2.Wrap the call behind your existing interface
Keep whatever function your codebase already calls for enrichment and swap its body for an HTTPS request. Nothing upstream of that function needs to change, which keeps the diff small and the rollback trivial.
3.Compare on real traffic, then drop the artifact
Run both sources side by side for a week, review the disagreements, adjust thresholds, then remove the database from your build and your release checklist.
Try it against your own traffic
Run a sample of addresses through the bulk tool, compare the verdicts with what you get today, and only then decide.