How to Migrate from IP2Location to IP Geo API in 2026: A Step-by-Step Drop-In Guide

7-minute read · 2026 code samples · honest rollback plan

This is the practical companion to the IP2Location alternative comparison → and the head-on review of IP2Location vs IP Geo API →. Those two pages tell you whether to switch. This page tells you how — including the three packaging and field-shape gotchas no other migration guide is honest about.

TL;DR — most IP2Location → IP Geo API migrations land in half an engineering day for REST callers, and roughly one full day for teams currently consuming the BIN/CSV/MMDB downloadable database files. The real work is not the swap itself; it is decommissioning the monthly DB-sync cycle, unbundling the IP2Proxy SKU (proxy / VPN / Tor flags move from a separately-licensed product to inline fields), and converting an annual USD prepay invoice to a monthly EUR subscription with iDEAL / SEPA / Bancontact at checkout.

Who this guide is for

You currently use IP2Location in one of three shapes:

• REST callers hitting https://api.ip2location.io/?key=…&ip=…&format=json (and possibly the IP2Proxy REST companion at https://api.ip2proxy.io/?key=…&ip=…).
• BIN / CSV / MMDB callers loading a downloaded IP2Location database file (DB1 through DB26, plus PX1–PX11 for proxy data) via the official Python / Node / Go / PHP libraries (IP2Location.IP2Location, ip2location-nodejs, ip2locationdb).
• Hybrid — REST in production hot paths, BIN files in nightly batch jobs.

…and you’ve decided that the BIN-sync cycle, the dual-product IP2Proxy license, USD-only annual prepay invoices, and the non-EU vendor HQ (Penang, Malaysia) cost more than they should. You want a REST replacement that:

• Returns a JSON shape close enough to IP2Location’s REST country_code / region_name / city_name flat response that downstream consumers don’t have to be rewritten.
• Bundles VPN / proxy / Tor / datacenter flags into the same response on every plan, free, with no IP2Proxy quota multiplier and no second invoice.
• Bills in EUR monthly (cancel anytime) with iDEAL / Bancontact / SEPA at checkout — not USD annual prepay.
• Is contractually EU-hosted with no Article 44/45 transfer-impact-assessment for IP visitor data.
• Removes the recurring ops task of pulling, validating, and redeploying a multi-GB DB file every month.

If those five boxes are unchecked — pause and read the vs comparison → first. The tradeoffs are real, especially if you actively need offline / air-gapped lookups for on-prem deployments, sub-millisecond local-process latency at multi-million-lookup-per-second scale, or PX11-tier fields like weather_station_code, mcc / mnc, iab_category, or elevation we don’t expose.

The 7-step migration checklist

1. Inventory every call site that hits ip2location.io, api.ip2proxy.io, OR loads a .bin / .csv / .mmdb IP2Location file.
2. Map your fields to the IP2Location-compatibility response (?format=ip2location).
3. Add a feature flag so you can switch any call site between providers.
4. Wire a 60-second cache in front of the API client (in-memory or Redis).
5. Deploy in shadow mode — call both, log differences, serve IP2Location responses.
6. Cut over gradually — 10% → 50% → 100% of traffic over 48 hours.
7. Decommission — cancel both DB-license and IP2Proxy, archive USD annual invoice, drop the BIN-sync cron.

The rest of this post walks each step with copy-paste code.

Step 1 — Inventory call sites

Run this in the repo root before touching anything:

git grep -nE "ip2location|ip2proxy|IP2Location|\\.BIN|\\.bin|IP2LOCATION_KEY" -- ':!*.lock' ':!*.md'

Most teams find 1-6 call sites: one for the main REST / lookup, optionally one for IP2Proxy REST, plus any number of BIN-file loaders (IP2Location.IP2Location("/var/lib/IP2LOCATION-LITE-DB11.BIN"), new IP2Location.IP2Location_init("/data/IP2PROXY-PX10.BIN")). The BIN-loader paths are the higher-leverage swap target — those are the call sites that today require a monthly DB pull, multi-GB redeploy, and version-skew checks across every app server. Audit each one; teams typically find one nightly cron job that nobody owns refreshing the file.

Watch-out: the BIN loaders are usually process-local singletons instantiated at app startup. Hot-reload semantics differ across the official libraries (pyIP2Location re-mmaps lazily; ip2location-nodejs requires a process restart on file replace; the Go module supports Open + Close). The new HTTP client is per-request stateless, so the migration eliminates this entire class of “is the lookup table fresh on every pod after deploy?” questions.

Step 2 — Map the fields

IP2Location’s REST API returns a flat JSON shape with sub-tier fields gated by your DB package:

{
  "ip": "8.8.8.8",
  "country_code": "US",
  "country_name": "United States of America",
  "region_name": "California",
  "city_name": "Mountain View",
  "latitude": 37.405992,
  "longitude": -122.078515,
  "zip_code": "94043",
  "time_zone": "-07:00",
  "asn": "15169",
  "as": "Google LLC",
  "is_proxy": false
}

…and the BIN/CSV local-lookup shape is similar but with package-specific column names. The DB package number determines which fields are populated: DB1 = country only; DB11 = country + region + city + lat/lng + ZIP + timezone; DB23 = +ASN/AS; DB26 = +usage type / category. PX packages (PX1-PX11) gate the proxy block.

IP Geo API ships an ?format=ip2location compatibility shim that returns the same flat shape so most call sites stop noticing the swap. The mapping for the fields ~95% of integrations rely on:

Fields the shim does not cover (documented gaps): domain (DB13+ — reverse DNS lookup at lookup time; we expose this via a separate path on the Business plan), iab_category (PX11 — IAB content categories; specialty ad-tech field, low signal for most use cases), mcc / mnc / mobile_brand (PX10 — mobile carrier codes; consider a dedicated mobile-network vendor if load-bearing), weather_station_code / weather_station_name (PX9 — nearest-weather-station; we do not expose this), elevation (PX8 — geographic elevation in metres; trivially derivable from lat/lng via a free elevation API), address_type ("U" unicast / "A" anycast — niche), and the entire district / category / time_zone_name (IANA-string variant, only on PX11) blocks. If your code reads any of those, list them as blockers and decide per call site whether to drop the dependency or keep IP2Location for that path only (hybrid pattern — see the comparison page →).

Step 3 — Feature flag, then drop-in client

Python (was IP2Location BIN-file singleton)

# before — BIN file loaded at module import, requires monthly file refresh
import IP2Location

DB = IP2Location.IP2Location("/var/lib/IP2LOCATION-DB11.BIN")  # multi-GB file

def lookup_country(ip: str) -> str:
    rec = DB.get_all(ip)
    return rec.country_short

# after — drop-in via the ip2location-compatibility shim, no file
import os, requests
from functools import lru_cache

API_KEY = os.environ["IPGEO_API_KEY"]
USE_IPGEO = os.environ.get("USE_IPGEO_API", "0") == "1"   # feature flag

@lru_cache(maxsize=10_000)
def _lookup(ip: str) -> dict:
    r = requests.get(
        f"https://api.ipgeo.10b.app/v1/{ip}",
        headers={"Authorization": f"Bearer {API_KEY}"},
        params={"format": "ip2location"},
        timeout=2.0,
    )
    r.raise_for_status()
    return r.json()

def lookup_country(ip: str) -> str:
    if USE_IPGEO:
        return _lookup(ip)["country_code"]      # flat shape — no rewrite
    rec = DB.get_all(ip)
    return rec.country_short

Two structural deltas on the migration: (a) the BIN file is gone — no more multi-GB artefact in /var/lib, no more monthly refresh cron, no more IP2Location_BIN_PATH env var, no more du -sh discipline; (b) the API key now lives in an Authorization: Bearer … header that does not appear in URL logs or browser history (IP2Location REST also used ?key=… query-string auth; if you were on the REST product before, treat the existing key as already-leaked across nginx, Cloudflare, APM, and Sentry logs).

Node / TypeScript (was ip2location-nodejs BIN loader)

// before
import IP2Location from "ip2location-nodejs";
const db = new IP2Location();
db.open("/var/lib/IP2LOCATION-DB11.BIN");

const rec = db.getAll(ip);
const country = rec.country_short;

// after — drop-in
const cache = new Map<string, any>();
export async function geoLookup(ip: string) {
  if (process.env.USE_IPGEO_API !== "1") {
    return db.getAll(ip);   // legacy BIN path
  }
  if (cache.has(ip)) return cache.get(ip);
  const r = await fetch(
    `https://api.ipgeo.10b.app/v1/${ip}?format=ip2location`,
    { headers: { Authorization: `Bearer ${process.env.IPGEO_API_KEY!}` } }
  );
  if (!r.ok) throw new Error(`ipgeo ${r.status}`);
  const j = await r.json();
  cache.set(ip, j);
  setTimeout(() => cache.delete(ip), 60_000);   // 60-s TTL
  return j;
}

Go

// after — drop-in via the ip2location-compatibility shim
url := fmt.Sprintf("https://api.ipgeo.10b.app/v1/%s?format=ip2location", ip)
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
req.Header.Set("Authorization", "Bearer "+os.Getenv("IPGEO_API_KEY"))
resp, err := httpClient.Do(req)
// ... unmarshal into your existing IP2Location-shaped struct

Step 4 — Cache layer (the step everyone skips)

A naive 1-call-per-request integration will burn through IP Geo API’s free 1K-req/day cap in the first hour of any production traffic. The Starter tier (€29/mo for 100K req/mo) is fine for most apps, but a 60-second cache typically deflects 70-90% of calls at zero cost — and matters far less for ex-IP2Location callers who used to pay an annual prepay irrespective of volume.

• Single-pod / serverless Lambda: Python lru_cache or a Map in Node, sized 10k entries.
• Multi-pod web: Redis SETEX <ip> 60 <json> or your existing distributed cache.
• Edge / CDN: Cloudflare Workers KV with a 60-300 s TTL.

If you want strict cache-miss bounds, add a per-host concurrency limiter so only one in-flight call per IP is ever issued. Bonus: a single cached response on the new client covers what previously required two DB lookups (DB11 + PX10 for proxy data) on IP2Location, which roughly halves your effective lookup volume on the threat-detection path. Note the structural difference: BIN-file callers used to pay zero per-lookup at runtime (process-local DB), so cache-hit-rate is less of a cost lever and more a latency lever — a cached HTTP response is ~0 ms vs ~5-15 ms over the wire even on warm TCP, which can matter on hot paths.

Step 5 — Shadow mode (the step that builds trust)

Before flipping any user-facing path: call both APIs and compare.

def lookup_country(ip: str) -> str:
    legacy = DB.get_all(ip).country_short
    if SHADOW_MODE:
        try:
            new = _lookup(ip)["country_code"]
            if new != legacy:
                logger.warning("ip2location-shadow-mismatch",
                               extra={"ip": ip, "legacy": legacy, "new": new})
        except Exception as e:
            logger.error("ip2location-shadow-error",
                         extra={"ip": ip, "error": str(e)})
    return legacy

Run shadow mode for 24-48 hours. The mismatch rate on country-level data is typically <0.5% (mostly stale BIN snapshots vs daily-refreshed managed data — IP2Location BIN files are released monthly, so a freshly-deployed BIN file matches our daily-refreshed data closely on day one and drifts as the month progresses). City-level is 1-3%. ASN naming is the noisiest signal — both providers ship the same numeric ASN, but the as (IP2Location) and network.organization (IP Geo API native) field can differ in casing or punctuation ("Google LLC" vs "GOOGLE"). The as field on the shim re-formats to match IP2Location’s casing convention.

The single biggest mismatch class for IP2Location is the proxy / VPN / Tor flag block: the legacy BIN/REST path returns a binary is_proxy plus a proxy_type enum ("VPN" / "TOR" / "DCH" / "PUB" / "WEB" / "SES" / "RES"), and the data is only populated if you have a PX-tier license — otherwise the field is absent or "-". IP Geo API returns four boolean flags inline (is_proxy / is_vpn / is_tor / is_datacenter) on every plan including free. Treat absent-vs-populated as a known-good signal, not a mismatch. For most fraud / analytics rules the binary is_proxy is the only field that matters; pin your match logic to that.

Step 6 — Gradual cutover

Once shadow logs are clean, flip a percentage of traffic via your feature-flag system (LaunchDarkly, Unleash, or a hashed-IP rollout):

import hashlib

def use_ipgeo(ip: str, percent: int) -> bool:
    h = int(hashlib.md5(ip.encode()).hexdigest(), 16)
    return (h % 100) < percent

Recommended ladder: 10% → 50% → 100% over 48 hours. Watch your existing fraud-flag dashboards for unexpected spikes; the bundled threat-flag block exposes signals that an IP2Location DB11 license (without the PX-tier proxy package) did not, so if you wire is_vpn=true into a soft-block rule you may see a 5-15% bump in flagged sessions. This is not a regression — it is the threat data you were paying for separately on the IP2Proxy product line, now bundled inline.

Step 7 — Decommission

Once 100% has been on IP Geo API for >7 days with no incidents:

1. Cancel both DB licenses in the IP2Location account portal — your geolocation DB (DB1-DB26) and IP2Proxy (PX1-PX11) if you had it. The two product lines bill separately on annual invoices; cancelling DB does not cancel IP2Proxy. Annual prepay is non-refundable for the remainder of the term, so plan the cutover ideally a month before your renewal date. Most teams forget this and end up paying for one more year while running on IP Geo API in parallel.
2. Drop the BIN-sync cron job. This is usually a wget + checksum + mv + service-reload script in /etc/cron.monthly, plus any matching Ansible / Terraform / Kubernetes ConfigMap that ships the file. Check /var/log/cron, crontab -l, your Ansible roles, and your CI pipelines for any reference to IP2LOCATION- or IP2PROXY- filenames.
3. Delete the BIN files from /var/lib, your container images, and your S3 / object-storage backups. A typical DB11+PX10 footprint is 1-3 GB per file; container-image bloat is a real win on rebuild time and registry storage cost.
4. Remove the IP2LOCATION_KEY / IP2LOCATION_BIN_PATH env vars from CI / production / staging.
5. Cancel the IP2Location Stripe USD recurring invoice (if you were on REST) — most teams forget the duplicate-invoice line until accounting flags it next quarter.
6. Delete the legacy fallback branch from your code (keep the feature-flag scaffold for the next migration).
7. Update your DPIA / Article 30 record — processor change from IP2Location (Penang, Malaysia) to corem6 BV (NL/EU). The Article 44/45 transfer-impact-assessment for non-adequacy-country processing of IP visitor data is removed from your record.

The 7 gotchas teams hit in week one

1. Annual prepay non-refundable. IP2Location’s annual licensing model means cutting over mid-year leaves money on the table. Plan the migration to land 1-2 months before renewal so the account expires naturally rather than overlapping with your new monthly EUR subscription. If you’re already mid-term, the math may favor running both in parallel until renewal.
2. Two product lines on the invoice, not one. If you used both DB-tier (geolocation) and PX-tier (IP2Proxy), they bill on separate annual invoices. Cancel both, or you’ll renew IP2Proxy automatically a year after cancelling the geolocation DB.
3. asn string-of-digits vs integer. IP2Location returns "15169" (string of digits, no AS prefix). IP Geo API native returns 15169 (integer); the shim preserves the string format on the asn field but exposes the integer at network.asn. Code that does int(asn) on the legacy field continues to work; code that reads network.asn as a string will break. Pin a unit test on the type before flipping.
4. time_zone offset-string vs IANA-name. IP2Location returns "-07:00" (raw UTC offset). IP Geo API native returns "America/Los_Angeles" (IANA timezone name); the shim preserves the offset string at time_zone but exposes the IANA name at location.timezone. The IANA name is strictly better — it survives DST transitions and is the canonical input for Intl.DateTimeFormat / pytz / zoneinfo. But code that does string comparisons on "-07:00" will break if you mix paths.
5. proxy_type enum vs split booleans. IP2Location returns proxy_type: "VPN" (a string-enum that can be "VPN" / "TOR" / "DCH" / "PUB" / "WEB" / "SES" / "RES"). IP Geo API splits these into four booleans (is_vpn / is_tor / is_datacenter / is_proxy). The shim derives the legacy enum string from the booleans (highest-priority match wins), but if you have a switch statement on every enum value, the "PUB" / "WEB" / "SES" / "RES" granular sub-types collapse into the residual is_proxy=true with is_vpn=is_tor=is_datacenter=false. Most fraud rules don’t use the sub-types, but check yours.
6. No cache layer. Quota burn in 4-6 hours on the free tier (1K/day cap). Add the cache before flipping the flag — especially relevant for ex-BIN-file callers used to “free at runtime”.
7. Outbound HTTPS blocked. Production VPC egress rules deny api.ipgeo.10b.app. Get firewall change scheduled before cutover. IP2Location’s hostname (api.ip2location.io / api.ip2proxy.io) was likely already allowlisted; the new hostname is not. Same applies to your CSP if you call from the browser.

What you’ll see in week two

• 70-90% cache-hit rate if step 4 was done right.
• ~30-50% bill reduction on the same volume once the duplicate IP2Proxy SKU is cancelled and the annual USD prepay is replaced by monthly EUR (€29/mo for 100K vs ~$200/yr DB11 + ~$200/yr IP2Proxy LITE = ~$400/yr ≈ $33/mo — and the EUR-month cuts the FX-volatility line on your forecast).
• Smaller deployment artefacts — multi-GB BIN files removed from container images and /var/lib. Rebuild time, registry storage cost, and pod cold-start time all improve measurably (1-3 GB per file × number of replicas).
• VPN / Tor / proxy / datacenter flags on every response, free — no separate IP2Proxy SKU, no separate license, no second invoice.
• API key in headers, not URLs — clean nginx/Cloudflare/APM logs going forward.
• Cleaner DPO conversation at your next compliance review — EU-only contractually, no Article 44/45 transfer-impact-assessment for IP visitor data leaving the EEA toward Penang, Malaysia.
• No more monthly DB-sync cron. That’s the recurring operational task most teams underestimate the cost of: someone owns it, someone validates checksums, someone notices when it silently fails.

Pairing pages

• IP2Location alternative comparison → — full feature matrix, REST-vs-BIN-vs-MMDB delivery model, EU-residency wedge, free-tier specs.
• IP Geo API vs IP2Location in 2026 → — narrative companion: when IP2Location’s offline DB still wins.
• API reference → — endpoint, parameters, error codes (ships with paid tiers).
• Pricing → — EUR 0 / 29 / 99 tiers, no overage surprises.

FAQ

How long does a real IP2Location migration take? For a single-stack web app calling the REST API with 1-4 call sites and a working CI: half an engineering day end-to-end. Multi-stack monorepos with BIN-file loaders in 5+ services: 1-2 days, mostly in service-by-service swap-out + cache-layer wiring + cron decommission. The annual-prepay-renewal-window planning is the time sink most teams underestimate, not the field-shape diff — put it on the cutover checklist 60 days ahead.

Will my IP2Location-shaped tests still pass? Yes — the compatibility shim returns the same flat JSON shape for the supported field set, including the country_code / region_name / city_name / time_zone / asn / as triplet that 95% of integrations rely on. For fields outside the shim (domain, iab_category, mcc, mnc, weather_station_code, elevation, address_type, time_zone_name IANA-string variant on PX11), mock the new client path or move that logic to a dedicated reference-data source.

What about the BIN/CSV/MMDB files I’m running locally? Replace the local-lookup call with an HTTP GET to IP Geo API. Cache hot IPs in Redis or equivalent for p95 latency. The migration is conceptually simpler than the REST-to-REST swap because the BIN files have a more constrained API surface — the official libraries all expose get_all(ip) or equivalent, and you can wrap the new HTTP client in a function with the same signature. The trade-off: you lose process-local sub-millisecond latency and gain ~5-15 ms of network latency per uncached lookup. If that delta breaks an SLA, keep IP2Location for that specific path and migrate everything else (hybrid pattern). For >99% of web apps, dashboards, and SaaS backends, the latency delta is invisible compared to your existing per-request budget.

What about IP2Proxy specifically? IP2Proxy is consolidated into the bundled threat block (is_proxy, is_vpn, is_tor, is_datacenter) on every IP Geo API response, including free tier. If you had a PX-tier license, the migration removes one annual invoice and one DB-sync cycle. The proxy_type string-enum ("VPN" / "TOR" / "DCH" / "PUB" / "WEB" / "SES" / "RES") is approximated by the four booleans; the granular "PUB" / "WEB" / "SES" / "RES" sub-types collapse into the residual is_proxy=true case. If you use those sub-types in fraud-rule branching, audit those rules before flipping.

What’s the rollback story if something goes wrong? The feature flag gives you a 1-second flip back to IP2Location. Keep the IP2Location integration working for at least 30 days post-cutover; if you’re on annual prepay you’ve already paid for the remainder of the term, so leaving it as instant-fallback insurance costs you nothing. The IP2Proxy SKU you can leave running too for the same reason — sunk cost, may as well use it as belt-and-suspenders.

Can I migrate one service at a time? Yes — and it’s the recommended approach. Each call site is independent. Migrate the lowest-risk one first (often a dashboard analytics path or a server-side log enrichment job), measure for a week, then move to the next. There is no all-or-nothing requirement.

Do you support a /bulk endpoint like IP2Location’s BIN local-lookup? IP2Location does not ship a REST /bulk endpoint — bulk users typically use the local DB file. We support a JSON POST to /v1/bulk with up to 100 IPs per call (paginate for larger batches). The response is a flat array; the per-IP response shape is identical to the single-lookup ?format=ip2location response. This is one of the biggest workflow improvements for ex-BIN-file batch consumers — no DB sync, no process restart, no version skew, just an HTTP POST.

What if I was on the IP2Location LITE free tier? Then the migration math shifts away from cost (both LITE and our free 1K-req/day are free) toward feature gain: LITE comes with a CC-BY-SA attribution requirement and ships only the country-level DB on a monthly refresh; our free tier ships full city + ASN + threat-block on a daily refresh with no attribution required. Side-project teams that “just need geo + light bot detection” usually find the migration is a net feature gain at zero cost change.

Why does IP2Location split DB and PX product lines at all? Historically the proxy/VPN data sources were licensed and updated separately, and IP2Location passed through that packaging. Our pricing posture is “threat is a baseline expectation in 2026, not an upsell” — we vertically integrated the threat data into one quota, one invoice, one response. That difference in posture is the single biggest reason teams hit this migration guide.

Related migration & comparison reading

• How to Migrate from MaxMind GeoIP2 to IP Geo API in 2026 — sibling migration guide for the database-download incumbent
• How to Migrate from ipinfo.io to IP Geo API in 2026 — sibling migration guide for the dominant North-American REST incumbent
• How to Migrate from ipstack to IP Geo API in 2026 — sibling migration guide for the apilayer-published REST product
• How to Migrate from ipapi.co to IP Geo API in 2026 — sibling migration guide with attribution-backlink and free-tier rate-limit fragmentation focus
• How to Migrate from ipgeolocation.io to IP Geo API in 2026 — sibling migration guide for the bundled-endpoints REST incumbent (Security-API SKU consolidation)
• How to Migrate from DB-IP to IP Geo API in 2026 — sibling migration guide for the EU-headquartered (Brussels) MMDB-download incumbent (CC-BY-4.0 attribution scrub, IP-to-Threat / Anonymous / Datacenter SKU consolidation)
• IP Geo API vs IP2Location in 2026 — narrative head-on with REST-vs-BIN TCO math
• IP Geo API vs ipinfo.io in 2026 — when ipinfo.io still wins
• IP Geo API vs MaxMind GeoIP2 in 2026 — managed API vs self-hosted GeoIP2 dataset trade-offs
• IP Geo API vs ipstack in 2026 — pricing, throughput and threat-intel comparison
• IP Geo API vs ipapi.co in 2026 — feature parity, attribution backlink, EUR billing
• IP Geo API vs ipgeolocation.io in 2026 — bundled-endpoints + Security-API SKU separation
• IP Geo API vs DB-IP in 2026 — REST-first vs MMDB-download EU-vs-EU

Industry deep-dives

• IP Geolocation for Fintech — KYC, Sanctions Screening, Fraud, and EU Residency → — fintech-specific deep-dive: the three IP-control surfaces (KYC country-of-origin, OFAC/EU sanctions, payment-fraud risk), EU-hosted GDPR posture, EUR billing, ASN-level hosting detection, and ≤40 ms median EU-edge latency for 800-1200 ms PSP authorisation budgets.

• IP Geolocation for Ad-Tech — RTB Enrichment, SIVT/IVT Filtering, and Click-Fraud Attribution → — ad-tech-specific deep-dive: the three IP-control surfaces (RTB bid enrichment with ≤40 ms latency budget + OpenRTB 2.6 device.geo/device.ext, SIVT/IVT filtering with IAB-confirmed datacenter ASN block-list, click-fraud post-back attribution + risk scoring), EU-hosted GDPR + ePrivacy + IAB-TCF v2.2 posture, bundled threat fields, ASN-level granularity, and predictable EUR billing.

• IP Geolocation for iGaming — Licence-Jurisdiction Enforcement, VPN-Circumvention Scoring, and Self-Exclusion Register Routing → — iGaming-specific deep-dive: the three IP-control surfaces (licence-jurisdiction enforcement with hard-fail-closed posture across MGA/UKGC/KSA/DGOJ/ANJ/ADM/DAS, anti-circumvention scoring with residential-proxy ASN block-list covering Bright Data + Oxylabs + Smartproxy + IPRoyal, self-exclusion register routing to GamStop/CRUKS/ROFUS/Spelpaus/OASIS by IP-country), EU-hosted GDPR + EGBA posture, bundled threat fields, ASN-level granularity, and predictable EUR billing.

• IP Geolocation for SaaS Monetization — Geo-Pricing, EU-VAT/DAC7 Tax-Routing, Trial-Abuse Scoring, and OFAC/EAR Export-Controls → — SaaS-specific deep-dive: the four IP-control surfaces (PPP-anchored geo-pricing with ≤40 ms checkout-flow budget, EU-VAT-MOSS + OECD DAC7 tax-routing to the right Stripe/Adyen/Braintree/Paddle tax-id, trial-abuse detection with residential-proxy ASN block-list across Bright Data/Oxylabs/Smartproxy/IPRoyal, and OFAC SDN + EAR export-controls feature-gating), EU-hosted GDPR posture, bundled threat fields, ASN-level granularity, and predictable EUR billing.

• IP Geolocation for Streaming Media — Content Licensing, VPN-Bypass Defence, CDN POP Steering, and SSAI Ad-Insertion → — Streaming-media-specific deep-dive: the four IP-control surfaces (per-territory licensing enforcement with hard-fail-closed HTTP 451 on ambiguous resolve, VPN/proxy/Tor circumvention defence with residential-proxy ASN block-list across Bright Data/Oxylabs/Smartproxy/IPRoyal, CDN POP steering and adaptive bitrate-ladder selection across Akamai/Cloudflare/Fastly/BunnyCDN/Lumen, and SSAI ad-insertion targeting with sports blackout windows via Haversine GPS-distance), ≤40 ms session-init budget on EU edges, studio-grade 24-month audit trail, threat fields on every plan, ASN-level granularity, and EU-hosted GDPR + AVMSD (Directive 2018/1808) posture.

• IP Geolocation for E-commerce — Tax-Jurisdiction Routing, BIN-vs-IP Carding Defence, PPP-Adjusted Currency Display, and Shipping-Zone Fulfilment Routing → — E-commerce-specific deep-dive: the four IP-control surfaces (EU OSS distance-sales 27-rate map + UK VAT 20% + CH-VAT 7.7% + NO MVA 25% + US Wayfair 13-state nexus + CA GST/HST per-province + AU/SG/IN/BR/JP GST/ICMS/JCT with sanctions hard-stop on IR/KP/SY/CU/BY/RU/MM/VE at checkout; BIN-vs-IP carding + refund-fraud 6-factor weighted score at place-order with residential-proxy ASN block-list across Bright Data/Oxylabs/Smartproxy/IPRoyal/Tier3; PPP-adjusted 7-tier pricebook on first paint with VPN/proxy fall-back to BIN-billing-country; 9-warehouse fulfilment routing FRA/AMS/MAD/MIL/DOV/IAD/LAX/DEL/SIN with DDP/DDU duty pre-calc and lithium/aerosol/prescription destination-gates), ≤40 ms checkout-first-paint budget, DAC7/GDPR/EU OSS audit posture, bundled threat fields on every plan, ASN-level granularity, and EUR billing.

• IP Geolocation for Healthcare — Cross-Border Telehealth Licensing, HIPAA PHI/EPHI Access Geofencing, EU Patient-Data Residency w/ Schrems II Routing, and Cross-Border Pharma + DEA Schedule Gating → — Healthcare-specific deep-dive: the four IP-control surfaces (cross-border telehealth licensure match at consult-init w/ US IMLC 41-state partial + CA/FL/NY/TX independent + EU MRPQ Directive 2005/36/EC + DE Bundesärztekammer + NL BIG + FR ONM + UK GMC + HTTP 451 hard-fail-closed on jurisdiction-mismatch + NO_RECIPROCITY hard-stop on IR/KP/SY/CU/BY/RU/MM/VE/AF/SO; HIPAA 45 CFR §164.308(a)(4) PHI/EPHI access geofencing w/ clinical-ASN allowlist Epic/Cerner/Allscripts/Mayo/MGH/Cleveland/Kaiser + residential-proxy ASN reject Bright Data/Oxylabs/Smartproxy/IPRoyal/Tier3 + home-office BAA-attested workstation allowlist + risk_score < 30 soft-allow; EU patient-data residency w/ GDPR Art. 9 special-category + EDPB Recommendations 01/2020 supplementary technical measures + Schrems II SCC flag for US-shard + routing to 6 EHR shards EU-FRA/EU-AMS/UK-LON/US-IAD/CA-YYZ/AU-SYD w/ VPN/proxy → fall-back to EU-FRA highest protection; cross-border pharma + controlled-substance gating w/ DEA Schedules I-V + Ryan Haight Act §3 in-person-eval requirement for telemed Rx + EU Falsified Medicines Directive 2011/62/EU originator-country audit + per-country bans for cannabis/CBD/psilocybin/MDMA/kratom), ≤40 ms consult-init budget, HIPAA/GDPR Art. 9/Schrems II/DEA/EU FMD audit posture, bundled threat fields on every plan, ASN-level granularity, and EUR billing.

• IP Geolocation for Travel + Hospitality — Geo-Rate Enforcement + Dynamic-Pricing per Booking Origin, OTA Carding + ATO Defence, OFAC/EU CONSILIUM/UK OFSI Sanctions Screening at Booking-Init, and GDS + EU OSS / DAC7 Reporting → — Travel/hospitality-specific deep-dive: the four IP-control surfaces (geo-rate enforcement + dynamic-pricing per booking origin w/ 8-tier pricebook T1 EU-Lux 1.00x → T8 Africa 0.75x + VPN/proxy/Tor fall-back to T2_NA_LUX anti-arbitrage + SANCTIONS_HARDSTOP on IR/KP/SY/CU/BY/RU/MM/VE/AF/SO HTTP 451 at search-render + BIN-billing-country pin at checkout; OTA carding + ATO defence at booking checkout w/ corporate-travel-platform ASN allowlist AS-CWT/Amex GBT/BCD/FCM/Egencia/Navan/Amadeus/Sabre fast-lane + consumer-OTA reject on VPN/Tor/relay + residential-proxy ASN block Bright Data/Oxylabs/Smartproxy/IPRoyal/Tier3 + 6-factor carding score threshold ≥70; OFAC + EU CONSILIUM + UK OFSI sanctions screening at booking-init w/ sanctioned-origin hard-stop regardless of session residency + EU 6AMLD compelled-disclosure on VPN/proxy + US-Cuba 31 CFR §515 General License gate + luxury-segment AML thresholds yacht €10K / private jet €20K / villa €5K/night / heli €3K + PEP screen + source-of-funds eval; GDS + inventory routing + EU OSS / DAC7 reporting w/ Amadeus EU/UK + Sabre US/CA + Travelport APAC + 27 EU-MS destination-VAT rates DE 19% → HU 27% + NO 25% + CH 8.1% + UK 20% + DAC7 Directive 2021/514 reportable-platform-operator evidence-log 5-year retention + Jan-31 lead-MS annual report), ≤40 ms search-render budget, OFAC/EU CONSILIUM/UK OFSI/DAC7/EU OSS/HOTREC audit posture, bundled threat fields on every plan, ASN-level granularity, and EUR billing.

Last reviewed 2026-05-10 · IP Geo API team · Comments / corrections: hello@ipgeo.10b.app

Pairs with the full IP2Location alternative comparison page and the head-on IP Geo API vs IP2Location review.