DEV Community: Abdul Mateen

How to Detect Residential Proxies in Your Application

Abdul Mateen — Fri, 08 May 2026 01:41:39 +0000

Residential proxy detection is one of the most challenging problems in IP-based threat intelligence. VPNs run on known datacenter IP ranges; you can blocklist them. Tor exit nodes publish their addresses. Datacenter proxies sit on hosting ASNs that reputation databases flag in hours. Residential proxies do none of that. They route traffic through real consumer ISP connections (Comcast, Vodafone, Jio, Deutsche Telekom), making every request look like it comes from someone's living room.

The FBI published a PSA in March 2026 warning that residential proxies have become a standard tool for credential stuffing, account takeovers, and purchase fraud. Google's Threat Intelligence team disrupted what they called the largest residential proxy network a month earlier. The threat is not emerging. It's operational.

This tutorial walks through detecting residential proxy traffic using an IP security API, with production code in cURL, Python, and Node.js.

TL;DR

Residential proxies use real ISP-assigned IPs, so VPN blocklists and datacenter ASN checks miss them.
API-based detection matches IPs against known residential proxy networks and returns provider attribution, confidence scores, and a composite threat score.
The examples below use a dedicated security endpoint that returns 17 fields per IP, including is_residential_proxy with provider names.
Use confidence scores and threat scores to add friction rather than hard-blocking. The same IP may serve both proxy traffic and legitimate users.

Why residential proxies bypass traditional detection

VPN detection is a solved problem (mostly). Commercial VPN providers run dedicated server infrastructure on hosting ASNs. NordVPN, ExpressVPN, Mullvad all operate on IP ranges that every major reputation database can flag within days.

Residential proxies work differently. They source IPs through three channels:

Embedded SDKs. Proxy providers pay mobile app developers to bundle their SDK. When someone installs the app, their device becomes a proxy exit node. The FBI PSA specifically calls this out as the most common sourcing method.

Peer-to-peer bandwidth sharing. "Earn money from your internet connection" apps funnel traffic through consumer devices. Users opt in without understanding their connection will be used for credential stuffing or ad fraud.

Compromised devices. Malware turns IoT devices, routers, and set-top boxes into proxy nodes. Trend Micro documented residential proxy providers in eastern Asia shipping pre-infected Android devices with proxy SDKs installed at the factory.

The result: proxy traffic originates from IPs assigned to Comcast, Jio, Telekom, and other consumer ISPs. To a traditional IP reputation system, it looks like a legitimate user.

How bad is the false negative problem? In 2024, Peakhour tested five major IP intelligence services against 25 IPs that had been actively used as residential proxies within the previous five minutes. MaxMind detected 0 out of 25. IPQualityScore detected 6 out of 25. proxycheck.io detected 0 out of 25. Cloudflare's research found that 4 out of 5 requests from residential proxy IPs are legitimate traffic from the device's real owner. That ratio is why hard-blocking creates unacceptable collateral damage.

What to look for in a detection API

Several IP intelligence APIs offer proxy detection: Spur, IPQualityScore, IPGeolocation, IPinfo, proxycheck.io, IP2Proxy, and others. Before picking one, check for:

A dedicated residential proxy flag separate from the generic is_proxy field. vpnapi.io, IPstack, and AbstractAPI return boolean proxy flags but don't distinguish residential proxies from datacenter proxies.

Provider attribution. Knowing an IP is "a proxy" is less useful than knowing it's Oxylabs, 922 Proxy, or Bright Data. Provider names let you build granular rules.

Confidence scores, not just boolean flags. A binary yes/no produces false positives on mobile carriers and large ISPs sharing IPs across thousands of users via CGNAT.

A composite threat score. An IP might simultaneously be a residential proxy, a known attacker, and a spam source. A composite score saves you from writing the aggregation logic.

Update frequency. Residential proxy IPs churn faster than VPN server IPs. A database that refreshes weekly will miss the majority of active endpoints.

I'll use ipgeolocation.io for the examples because the Security API returns a dedicated is_residential_proxy flag with provider names and confidence scores on all paid plans starting at $19/month. The same approach works with any API that provides equivalent signals.

Making the API call

The dedicated security endpoint:

curl -s "https://api.ipgeolocation.io/v3/security?apiKey=$IPGEO_API_KEY&ip=85.117.56.115" | python3 -m json.tool

{
    "ip": "85.117.56.115",
    "security": {
        "threat_score": 75,
        "is_tor": false,
        "is_proxy": true,
        "proxy_provider_names": [
            "Evomi Proxy",
            "DataImpulse",
            "NetNut",
            "Proxy Scrape"
        ],
        "proxy_confidence_score": 90,
        "proxy_last_seen": "2026-04-22",
        "is_residential_proxy": true,
        "is_vpn": true,
        "vpn_provider_names": [
            "Bestproxyswitcher VPN"
        ],
        "vpn_confidence_score": 90,
        "vpn_last_seen": "2026-03-19",
        "is_relay": false,
        "relay_provider_name": "",
        "is_anonymous": true,
        "is_known_attacker": true,
        "is_bot": false,
        "is_spam": false,
        "is_cloud_provider": false,
        "cloud_provider_name": ""
    }
}

A few things to notice here. The is_proxy flag is true and is_residential_proxy is also true, so this IP is being used by a residential proxy network. The proxy_provider_names array identifies the specific provider (Evomi Proxy, a commercial residential proxy service). The proxy_confidence_score of 85 means the API has high confidence in this classification. And threat_score of 75 places this IP in the "high risk" range, where you'd typically add friction.

Compare that to what a VPN-only API would return: a generic boolean flag with no provider name, no confidence score, and often no residential proxy flag at all. The difference between "this IP is suspicious" and "this IP is on the Evomy Proxy residential network with 85% confidence" is the difference between a useful detection system and a noisy one.

For the full API documentation, including field-level reference tables and error codes, see the docs.

Python implementation

import os
import requests

def check_residential_proxy(ip_address):
    """Check if an IP is a residential proxy. Returns a dict with detection results."""
    api_key = os.environ.get("IPGEO_API_KEY")
    if not api_key:
        raise EnvironmentError("IPGEO_API_KEY environment variable not set")

    try:
        response = requests.get(
            "https://api.ipgeolocation.io/v3/security",
            params={"apiKey": api_key, "ip": ip_address},
            timeout=(1.0, 1.5),  # connect timeout, read timeout
        )
        response.raise_for_status()
    except requests.exceptions.Timeout:
        # Fail open: if the API is unreachable, allow the request through
        return {"detected": False, "reason": "api_timeout", "action": "allow"}
    except requests.exceptions.RequestException as e:
        return {"detected": False, "reason": f"api_error: {e}", "action": "allow"}

    data = response.json()
    security = data.get("security", {})

    is_residential = security.get("is_residential_proxy", False)
    confidence = security.get("proxy_confidence_score", 0)
    threat_score = security.get("threat_score", 0)
    providers = security.get("proxy_provider_names", [])

    # Decision logic based on threat_score ranges
    if is_residential and confidence >= 70:
        if threat_score >= 80:
            action = "block"
        elif threat_score >= 45:
            action = "challenge"  # CAPTCHA, step-up auth, or rate limit
        else:
            action = "monitor"  # log but allow
    else:
        action = "allow"

    return {
        "detected": is_residential,
        "confidence": confidence,
        "threat_score": threat_score,
        "providers": providers,
        "action": action,
    }


result = check_residential_proxy("85.117.56.115")
print(f"Residential proxy: {result['detected']}")
print(f"Action: {result['action']}")
if result.get("providers"):
    print(f"Provider: {', '.join(result['providers'])}")

Pitfall: The timeout=(1.0, 1.5) matters. For an inline check on a login flow, anything slower degrades UX enough to hurt conversion. And the function fails open on API errors: if the API is unreachable, the request passes through. Failing closed means your login page breaks on every API hiccup. Fail open on detection; fail closed only on payment fraud flows where the cost of a miss exceeds the cost of a false block.

Node.js implementation

async function checkResidentialProxy(ipAddress) {
  const apiKey = process.env.IPGEO_API_KEY;
  if (!apiKey) {
    throw new Error("IPGEO_API_KEY environment variable not set");
  }

  const url = `https://api.ipgeolocation.io/v3/security?apiKey=${apiKey}&ip=${ipAddress}`;

  try {
    const response = await fetch(url, {
      signal: AbortSignal.timeout(1500), // 1.5s total timeout
    });

    if (!response.ok) {
      console.error(`Security API returned ${response.status}`);
      return { detected: false, action: "allow", reason: "api_error" };
    }

    const data = await response.json();
    const security = data?.security ?? {};

    const isResidential = security.is_residential_proxy ?? false;
    const confidence = security.proxy_confidence_score ?? 0;
    const threatScore = security.threat_score ?? 0;
    const providers = security.proxy_provider_names ?? [];

    let action = "allow";
    if (isResidential && confidence >= 70) {
      if (threatScore >= 80) action = "block";
      else if (threatScore >= 45) action = "challenge";
      else action = "monitor";
    }

    return { detected: isResidential, confidence, threatScore, providers, action };
  } catch (err) {
    // Fail open on network errors and timeouts
    console.error("Security API check failed:", err.message);
    return { detected: false, action: "allow", reason: "timeout_or_network" };
  }
}

AbortSignal.timeout(1500) kills the request after 1.5 seconds regardless of connection state. Optional chaining on data?.security handles partial or unexpected responses.

Building decision logic

The code uses a three-tier matrix based on threat_score:

1 to 19 (low risk): Allow the request. Even if is_residential_proxy is true, a low threat score with low confidence usually means a brief or historical proxy association. Log it.

45 to 79 (elevated risk): This is where most active residential proxy traffic lands. Add friction: CAPTCHA, email verification, step-up auth. Don't hard-block; the IP might serve legitimate users behind CGNAT.

80 to 100 (high risk): Multiple strong signals stacked together. Block or require manual review.

Pitfall: Indian mobile carriers (Jio, Airtel) route millions of users through a handful of public IPs via CGNAT. A residential proxy flag on a Jio IP with confidence 30 is likely noise. The same flag on a European broadband IP with confidence 90 is almost certainly a detection. Your decision function should treat confidence below 50 differently from confidence above 70.

Caching and rate considerations

Residential proxy IPs rotate fast. A scraper using Oxylabs or Bright Data might cycle exit nodes every request. That's why detection APIs exist, but it also means aggressive caching defeats the purpose.

For auth and fraud workflows, cache detection results for 5 to 15 minutes. For content personalization, 1 to 4 hours is fine. If you're processing logs after the fact, the bulk endpoint accepts up to 50,000 IPs per POST request.

What detection APIs can and cannot do

API-based detection catches known proxy networks. Oxylabs, Bright Data, 922 Proxy, SOAX, IPRoyal, and Smartproxy all operate at scale, and their IP pools are large enough to fingerprint.

What it won't catch: zero-day proxy infrastructure, small botnet-based networks, and proxies that load as separate software modules on compromised devices (a pattern Trend Micro flags as an emerging evasion technique).

Connection-level signals fill part of the gap. JA4+ TCP/TLS fingerprinting can detect proxied traffic based on packet characteristics that differ between direct and proxied connections. But JA4+ requires CDN or WAF-level access and is not something you add with an API call.

The practical recommendation: layer an IP intelligence API with behavioral analysis on your application side. An IP flagged as a residential proxy that also shows high login failure rates and automated navigation patterns is a much stronger signal than any single method alone.

A few extra notes

When traffic outgrows the free tier. The Security API costs 2 credits per lookup. At 150,000 credits/month on the Starter plan, that's plenty for login and checkout checks on a mid-traffic app. If you need per-request lookups on every page load, consider the downloadable residential proxy database instead.

Redis caching pattern. Store the threat_score and is_residential_proxy result with a 10-minute TTL keyed on the IP. Check Redis before the API call. This cuts redundant lookups by 70-80% on session-based traffic without serving dangerously stale results.

Fail-open vs fail-closed, stated explicitly. Every detection integration should document which mode it runs in. If your team can't answer "what happens when the security API is down?" without checking code, that's a gap worth closing before your next incident.

Use ASN Lookups to Spot Fraud Before It Hits Your App

Abdul Mateen — Mon, 04 May 2026 15:56:37 +0000

Most IP-based fraud checks stop at geolocation and VPN flags. That misses a layer of context sitting right there in the data: the autonomous system number.

A single ASN lookup tells you which organization controls the IP block your visitor is connecting from. It tells you whether that IP belongs to a residential ISP like Comcast (AS7922), a cloud provider like Hetzner (AS24940), or a VPN operator. That distinction matters. A login attempt from a Comcast residential IP and one from a Hetzner datacenter IP carry very different risk profiles, even if both geolocate to the same city.

This tutorial builds a risk-scoring function that combines ASN type classification with IP security signals (VPN detection, proxy detection, threat scoring) in a single API call. You will walk away with Express middleware you can drop into a Node.js app, plus equivalent Python code.

TL;DR

Every IP address belongs to exactly one ASN, which identifies the organization controlling that IP block
The ASN's type field (ISP, HOSTING, BUSINESS, EDUCATION) is a strong fraud signal because most automated attacks originate from HOSTING-type networks
Combining ASN type with VPN/proxy detection and threat scoring in one API call gives you a composite risk score without multiple vendor roundtrips
The tutorial builds a calculateRiskScore() function and Express middleware with caching, fail-open logic, and proper error handling

ASN data adds network-level context that geolocation and VPN flags alone cannot provide. Knowing that an IP belongs to a datacenter hosting provider changes a fraud decision differently than knowing it geolocates to Dallas. This tutorial shows how to make that distinction programmatically and act on it.

What an ASN tells you that geolocation doesn't

An autonomous system (AS) is a network, or collection of networks, operated by a single organization under a single routing policy. Each AS gets a unique number from a regional internet registry (ARIN, RIPE, APNIC, LACNIC, AFRINIC). There are roughly 115,000 active ASNs as of 2026.

The practical value for fraud detection is the ASN metadata, not the number itself. When you look up an IP's ASN, you get the organization name, its type classification, the country of registration, and the RIR that issued it. The type field is where the fraud signal lives.

Here is what a lookup returns for a Hetzner datacenter IP (49.12.0.0):

{
  "asn": {
    "as_number": "AS24940",
    "organization": "Hetzner Online GmbH",
    "type": "HOSTING",
    "country": "DE",
    "domain": "hetzner.com",
    "rir": "RIPE"
  }
}

And here is the same lookup for a Google corporate IP (8.8.8.8):

{
  "asn": {
    "as_number": "AS15169",
    "organization": "Google LLC",
    "type": "BUSINESS",
    "country": "US",
    "domain": "google.com",
    "rir": "ARIN"
  }
}

The type field classifies the ASN into categories like ISP (consumer broadband), HOSTING (cloud/datacenter), BUSINESS (corporate networks), and EDUCATION (university networks). This classification comes from analyzing the ASN's routing behavior, registered purpose, and allocation history.

Why does this matter for fraud? The Cybercrime Information Center's Q1 2025 data tracked malware activity by ASN and found DigitalOcean (AS14061) ranked #5 globally with 29,089 unique malware-hosting IPs from only 3 million routed addresses. Amazon's AS16509 had 13,459 malware addresses but spread across 210 million routed IPs. Hosting-type ASNs are disproportionately represented in malicious activity relative to their size.

A related ARIN-funded study by the DNS Research Federation (published January 2026) found that roughly 70% of reported malware URLs rely solely on IP addresses rather than domain names. That means DNS-based detection misses them entirely, and IP-level enrichment (including ASN data) is one of the few signals that catches them.

ASN type as a fraud signal

Here is how to interpret each type in a fraud context:

ISP is the expected type for real human users. Comcast (AS7922), Verizon (AS701), Deutsche Telekom (AS3320). Residential broadband. The vast majority of legitimate traffic comes from ISP-type ASNs. Low risk by itself, though compromised home machines and residential proxies use ISP ASNs too.

HOSTING is the high-attention category. AWS, Hetzner, DigitalOcean, OVH, Linode. Cloud VMs and dedicated servers. Legitimate users don't typically browse your app from a Hetzner VPS. When a login or signup comes from a HOSTING-type ASN, it is worth adding friction: a CAPTCHA, rate limiting, or manual review depending on your risk tolerance.

BUSINESS covers corporate networks. A login from a BUSINESS-type ASN is usually a company employee on a corporate VPN or office network. Medium context. Could be fine. Could be a compromised machine on a corporate network. Treat as neutral unless other signals (threat score, proxy flag) elevate it.

EDUCATION means university or research networks. Often legitimate. Also a common source of scanning and experimentation from campus WiFi. Low-to-medium risk.

Pitfall: ASN type is a prior, not a verdict. Blocking all HOSTING-type traffic would lock out developers who test from cloud VMs, monitoring services that health-check your endpoints, and legitimate webhook callbacks from SaaS platforms. Use ASN type to adjust a risk score, not as a binary block rule.

Fetch ASN and security data for an IP

Several providers return ASN data in their IP intelligence APIs: ipinfo, MaxMind GeoIP2, Team Cymru, IPLocate, and IPGeolocation.io all support ASN lookups. I will use IPGeolocation.io for the examples because a single call to the /v3/ipgeo endpoint returns ASN classification and security signals (VPN, proxy, threat score) together, which saves you a second API round-trip.

Note: ASN data is on the free tier (1,000 requests/day). The security signals (include=security) require a paid plan starting at $19/month for 150K requests. The combined call is what makes the fraud pipeline work, so the examples use the paid path.

curl

curl -s "https://api.ipgeolocation.io/v3/ipgeo?\
apiKey=${IPGEO_API_KEY}&\
ip=49.12.0.1&\
include=security"

{
  "ip": "49.12.0.1",
  "asn": {
    "as_number": "AS24940",
    "organization": "Hetzner Online GmbH",
    "type": "HOSTING",
    "country": "DE",
    "domain": "hetzner.com",
    "rir": "RIPE"
  },
  "security": {
    "threat_score": 80,
    "is_tor": false,
    "is_proxy": false,
    "proxy_provider_names": [],
    "proxy_confidence_score": 0,
    "proxy_last_seen": "",
    "is_residential_proxy": false,
    "is_vpn": false,
    "vpn_provider_names": [],
    "vpn_confidence_score": 0,
    "vpn_last_seen": "",
    "is_relay": false,
    "relay_provider_name": "",
    "is_anonymous": false,
    "is_known_attacker": false,
    "is_bot": false,
    "is_spam": false,
    "is_cloud_provider": true,
    "cloud_provider_name": "Hetzner Online GmbH"
  }
}

That is a lot more than Boolean flags. The security response includes provider names for VPNs and proxies when detected, confidence scores (0 to 100) indicating detection certainty, last-seen timestamps, and separate classifications for relays, bots, spam sources, known attackers, and cloud providers. For this Hetzner datacenter IP, the is_cloud_provider flag fires with the provider name, the threat score sits at 80, and the ASN type confirms HOSTING. Three independent signals pointing in the same direction.

Node.js

// fetchIpIntel.js
// Returns ASN + security data for a given IP address

const API_KEY = process.env.IPGEO_API_KEY;
const BASE_URL = 'https://api.ipgeolocation.io/v3/ipgeo';

async function fetchIpIntel(ip) {
  const params = new URLSearchParams({
    apiKey: API_KEY,
    ip,
    include: 'security',
  });

  try {
    const res = await fetch(`${BASE_URL}?${params}`, {
      signal: AbortSignal.timeout(1500), // Fail fast; don't hold the request
    });

    if (!res.ok) {
      throw new Error(`API returned ${res.status}: ${res.statusText}`);
    }

    return await res.json();
  } catch (err) {
    // Network timeout, DNS failure, or API error
    console.error(`IP intel lookup failed for ${ip}:`, err.message);
    return null;
  }
}

export { fetchIpIntel };

Python

# fetch_ip_intel.py
# Returns ASN + security data for a given IP address

import os
import requests

API_KEY = os.environ.get("IPGEO_API_KEY")
BASE_URL = "https://api.ipgeolocation.io/v3/ipgeo"


def fetch_ip_intel(ip: str) -> dict | None:
    try:
        resp = requests.get(
            BASE_URL,
            params={
                "apiKey": API_KEY,
                "ip": ip,
                "include": "security",
            },
            timeout=(1.0, 1.5),  # (connect, read) timeouts in seconds
        )
        resp.raise_for_status()
        return resp.json()
    except requests.RequestException as exc:
        print(f"IP intel lookup failed for {ip}: {exc}")
        return None

Both implementations include timeouts, error handling, and environment variable API keys. If the API is unreachable, they return null/None instead of raising. This matters for the next step.

Build a risk-scoring function

The risk function takes the combined ASN + security response and returns a numeric score with a decision. The thresholds below are a starting point. Tune them to your traffic.

Node.js

// riskScore.js
// Composite risk scoring from ASN type + security signals

const ASN_TYPE_RISK = {
  HOSTING: 30,    // Datacenter/cloud: high attention
  BUSINESS: 10,   // Corporate network: some attention
  EDUCATION: 5,   // University: low attention
  ISP: 0,         // Residential broadband: expected
};

function calculateRiskScore(data) {
  if (!data?.asn || !data?.security) {
    // Missing data = unknown risk. Return a middle score, not zero.
    return { score: 50, decision: 'CHALLENGE', reason: 'incomplete data' };
  }

  let score = 0;
  const factors = [];

  // ASN type classification
  const asnType = data.asn.type ?? 'UNKNOWN';
  const asnRisk = ASN_TYPE_RISK[asnType] ?? 15;
  score += asnRisk;
  if (asnRisk > 0) factors.push(`asn_type:${asnType}`);

  // VPN detection
  if (data.security.is_vpn) {
    score += 20;
    factors.push('vpn');
  }

  // Proxy detection (non-VPN proxies)
  if (data.security.is_proxy) {
    score += 25;
    factors.push('proxy');
  }

  // Residential proxy: hardest to detect, highest risk when present
  if (data.security.is_residential_proxy) {
    score += 30;
    factors.push('residential_proxy');
  }

  // Tor exit node
  if (data.security.is_tor) {
    score += 25;
    factors.push('tor');
  }

  // Known attacker: IP flagged in threat intelligence feeds
  if (data.security.is_known_attacker) {
    score += 35;
    factors.push('known_attacker');
  }

  // Bot traffic
  if (data.security.is_bot) {
    score += 20;
    factors.push('bot');
  }

  // Spam source
  if (data.security.is_spam) {
    score += 15;
    factors.push('spam');
  }

  // Cloud provider (corroborates HOSTING ASN type)
  if (data.security.is_cloud_provider) {
    score += 10;
    factors.push(`cloud:${data.security.cloud_provider_name || 'unknown'}`);
  }

  // API threat score (0-100), scaled to contribute up to 30 points
  const threatScore = data.security.threat_score ?? 0;
  const threatContribution = Math.round((threatScore / 100) * 30);
  score += threatContribution;
  if (threatContribution > 10) factors.push(`threat:${threatScore}`);

  // Cap at 100
  score = Math.min(score, 100);

  // Decision thresholds
  let decision;
  if (score < 20) decision = 'ALLOW';
  else if (score < 50) decision = 'CHALLENGE';
  else decision = 'BLOCK';

  return { score, decision, factors };
}

export { calculateRiskScore };

A few design choices worth calling out:

The ASN type contributes 0 to 30 base points. That is enough to push a borderline IP into CHALLENGE territory, but not enough to trigger BLOCK on its own. A Hetzner IP with no VPN flags and a low threat score scores 30 (CHALLENGE). Add a VPN flag and it jumps to 50 (BLOCK). That graduated response is the point.

is_known_attacker gets the highest individual weight (35 points) because it means the IP appears in threat intelligence feeds as a confirmed attacker. Residential proxies get 30 because they are the hardest signal to detect and almost always indicate fraud or scraping when present. The is_cloud_provider flag adds a modest 10 points on its own since it corroborates the ASN type rather than standing alone as evidence.

Missing data defaults to score 50 and CHALLENGE. This is a judgment call. If you can't determine the risk, adding friction (CAPTCHA, email verification) is safer than either allowing blindly or blocking based on no evidence.

Python

# risk_score.py
# Composite risk scoring from ASN type + security signals

ASN_TYPE_RISK = {
    "HOSTING": 30,
    "BUSINESS": 10,
    "EDUCATION": 5,
    "ISP": 0,
}


def calculate_risk_score(data: dict | None) -> dict:
    if not data or "asn" not in data or "security" not in data:
        return {"score": 50, "decision": "CHALLENGE", "reason": "incomplete data"}

    score = 0
    factors = []

    # ASN type
    asn_type = data["asn"].get("type", "UNKNOWN")
    asn_risk = ASN_TYPE_RISK.get(asn_type, 15)
    score += asn_risk
    if asn_risk > 0:
        factors.append(f"asn_type:{asn_type}")

    # Security flags
    sec = data["security"]
    if sec.get("is_vpn"):
        score += 20
        factors.append("vpn")
    if sec.get("is_proxy"):
        score += 25
        factors.append("proxy")
    if sec.get("is_residential_proxy"):
        score += 30
        factors.append("residential_proxy")
    if sec.get("is_tor"):
        score += 25
        factors.append("tor")
    if sec.get("is_known_attacker"):
        score += 35
        factors.append("known_attacker")
    if sec.get("is_bot"):
        score += 20
        factors.append("bot")
    if sec.get("is_spam"):
        score += 15
        factors.append("spam")
    if sec.get("is_cloud_provider"):
        score += 10
        factors.append(f"cloud:{sec.get('cloud_provider_name', 'unknown')}")

    # Threat score contribution (up to 30 points)
    threat = sec.get("threat_score", 0)
    threat_contrib = round((threat / 100) * 30)
    score += threat_contrib
    if threat_contrib > 10:
        factors.append(f"threat:{threat}")

    score = min(score, 100)

    if score < 20:
        decision = "ALLOW"
    elif score < 50:
        decision = "CHALLENGE"
    else:
        decision = "BLOCK"

    return {"score": score, "decision": decision, "factors": factors}

Wire it into Express middleware

Here is how the pieces fit together in a Node.js backend. The middleware runs on every request (or on sensitive routes like /login and /signup), caches results per IP, and attaches the risk assessment to req for downstream handlers.

// ipRiskMiddleware.js
import { fetchIpIntel } from './fetchIpIntel.js';
import { calculateRiskScore } from './riskScore.js';
import { createClient } from 'redis';

const redis = createClient({ url: process.env.REDIS_URL });
redis.on('error', (err) => console.error('Redis error:', err));
await redis.connect();

const CACHE_TTL = 900; // 15 minutes for security data

async function ipRiskMiddleware(req, res, next) {
  // Trust proxy must be configured in Express for this to work behind a load balancer.
  // Without it, req.ip returns the load balancer's IP, not the client's.
  const clientIp = req.ip;

  if (!clientIp) {
    req.riskScore = { score: 0, decision: 'ALLOW', factors: ['no_ip'] };
    return next();
  }

  try {
    // Check cache first
    const cached = await redis.get(`ip-risk:${clientIp}`);
    if (cached) {
      req.riskScore = JSON.parse(cached);
      return next();
    }

    const intel = await fetchIpIntel(clientIp);
    const risk = calculateRiskScore(intel);

    // Cache the result
    await redis.setEx(`ip-risk:${clientIp}`, CACHE_TTL, JSON.stringify(risk));

    req.riskScore = risk;
  } catch (err) {
    // Fail open: if anything breaks, let the request through.
    // For payment endpoints, you might want fail-closed instead.
    console.error('Risk middleware error:', err.message);
    req.riskScore = { score: 0, decision: 'ALLOW', factors: ['error_failopen'] };
  }

  next();
}

export { ipRiskMiddleware };

Usage in your Express app:

import express from 'express';
import { ipRiskMiddleware } from './ipRiskMiddleware.js';

const app = express();

// Enable trust proxy if behind nginx, Cloudflare, AWS ALB, etc.
// Without this, req.ip is wrong and everything downstream breaks.
app.set('trust proxy', true);

// Apply to sensitive routes
app.use('/login', ipRiskMiddleware);
app.use('/signup', ipRiskMiddleware);

app.post('/login', (req, res) => {
  const { score, decision, factors } = req.riskScore;

  if (decision === 'BLOCK') {
    // Log the attempt; don't tell the user why
    console.warn(`Blocked login: ip=${req.ip} score=${score} factors=${factors}`);
    return res.status(403).json({ error: 'Request blocked' });
  }

  if (decision === 'CHALLENGE') {
    // Require additional verification (CAPTCHA, email OTP, etc.)
    return res.status(200).json({ requiresChallenge: true, challengeType: 'captcha' });
  }

  // Proceed with normal login flow
  // ... your auth logic here
});

Tip: The middleware defaults to fail-open: if Redis is down, the API is unreachable, or anything else breaks, the request goes through with decision: 'ALLOW'. This is the right default for most web apps where availability matters more than blocking every threat. For payment processing, checkout flows, or high-value account actions, switch to fail-closed (return CHALLENGE or BLOCK on error) so an API outage does not leave a security gap.

What this catches (and what it doesn't)

Worth being honest about limits. ASN-based risk scoring is strongest against:

Datacenter-originating attacks. Credential stuffing bots running on AWS, Hetzner, or DigitalOcean VMs get flagged immediately because their ASN type is HOSTING. Combined with the threat score, these typically score 50+ and land in BLOCK territory. This is the highest-volume category of automated abuse, and ASN type catches it without maintaining IP blocklists.

VPN and proxy traffic. The security flags add 20 to 25 points on top of whatever the ASN type contributes. A consumer VPN like NordVPN on an ISP-type ASN still gets flagged through the VPN detection layer, and the combined score pushes it into CHALLENGE range.

Bot and scanner traffic. The API's threat_score aggregates signals from threat feeds, behavioral profiling, and known attacker databases. Bots hitting your endpoints from cloud infrastructure combine a high threat score with a HOSTING ASN type, which stacks into the BLOCK range.

The approach is weakest against:

Residential proxies. These are the hardest threat to catch because they route traffic through real ISP connections. The ASN type shows ISP (expected for legitimate users), and the IP itself may belong to an unsuspecting home user whose device is part of a proxy network. The is_residential_proxy flag helps, but detection rates for residential proxies are lower across the industry than for VPNs or datacenter proxies.

Compromised home machines. A botnet node on a residential Comcast connection has a clean ASN type (ISP) and may not trigger threat scoring until it is reported. IP-level signals alone are insufficient here; you need behavioral analytics at the application layer (login velocity, credential patterns, session anomalies).

Legitimate cloud traffic. Webhook callbacks from Stripe, monitoring probes from Datadog, or API calls from a customer's cloud deployment all come from HOSTING-type ASNs. The scoring function correctly flags them. You will need allowlists for known service IPs or a separate path for server-to-server calls that skips the risk middleware.

Go deeper: the dedicated ASN API

The fraud pipeline above uses the unified /v3/ipgeo endpoint, which returns ASN basics alongside security signals in one call. That is the right choice for per-request middleware where you want combined data with minimal latency.

But ipgeolocation.io also has a dedicated ASN endpoint (/v3/asn) that returns richer network topology data. This is useful for incident response, threat hunting, and understanding the network infrastructure behind suspicious traffic.

curl -s "https://api.ipgeolocation.io/v3/asn?\
apiKey=${IPGEO_API_KEY}&\
asn=24940&\
include=peers,upstreams,downstreams"

{
  "asn": {
    "as_number": "AS24940",
    "organization": "Hetzner Online GmbH",
    "country": "DE",
    "type": "HOSTING",
    "domain": "http://hetzner.com/",
    "date_allocated": "2002-06-03",
    "asn_name": "HETZNER-AS",
    "allocation_status": "ASSIGNED",
    "num_of_ipv4_routes": "86",
    "num_of_ipv6_routes": "6",
    "rir": "RIPE",
    "routes": [
      "78.46.0.0/15",
      "138.199.128.0/17",
      "185.189.230.0/24",
      "85.10.192.0/18",
      "185.228.8.0/23",
      "185.157.178.0/23",
      "65.21.0.0/16",
      ...
  ]
    "downstreams": [
      {
        "as_number": "AS202851",
        "description": "rackSPEED GmbH",
        "country": "DE"
      },...
    ],
    "peers": [
      {
        "as_number": "AS61851",
        "description": "Garra Telecom Ltda",
        "country": "BR"
      },...
    ],
    "upstreams": [
      {
        "as_number": "AS12552",
        "description": "GlobalConnect AB",
        "country": "SE"
      },...
    ]
  }
}

The dedicated endpoint adds fields that the unified endpoint does not return: asn_name (the short registry name like "HETZNER-AS"), allocation_status, route counts (num_of_ipv4_routes, num_of_ipv6_routes), and the optional network relationship data.

Where this data earns its keep:

Upstream analysis. If a suspicious ASN routes traffic through known bulletproof hosting upstreams, that is a stronger signal than ASN type alone. Some fraud operations use small ASNs with clean type classifications but route through upstream providers with poor abuse handling.

Peer clustering. An ASN that peers heavily with other known-bad ASNs may share infrastructure with them. During incident response, pulling the peer list helps you identify related networks to investigate.

Route counts. An ASN with 2 IPv4 routes is a small operation. One with 500+ is a large provider. The scale tells you whether a few bad IPs are coincidental or systemic.

IP prefix enumeration. Add include=routes to get every IP prefix announced by the ASN. Useful for building targeted blocklists during an active attack, or for retrospective analysis of log data against a suspect network.

This is not data you need in real-time middleware. It is data you query during investigation, threat hunting, or when building batch-processing pipelines that assess risk at the ASN level rather than per-IP.

A few extra notes

Cache aggressively. ASN data changes rarely. An IP's autonomous system stays the same for months or years. Security signals change faster but are still valid for 5 to 15 minutes. The middleware above caches combined results for 15 minutes, which keeps API usage well within plan limits even at high traffic volumes.

IPv6 works the same way. The API accepts both IPv4 and IPv6 addresses. The ASN lookup returns the same fields. No code changes needed, but make sure your IP extraction handles both formats (Express does this by default when trust proxy is configured).

Log the decision, not the raw IP. IP addresses are personal data under GDPR. If you operate in the EU or serve EU users, log the risk score, decision, and contributing factors rather than storing the raw IP alongside user records. The risk assessment is what you need for audit trails; the IP itself is not necessary after the decision is made.

Bulk lookups for historical analysis. If you are processing logs or running batch fraud analysis, the API supports up to 50,000 IPs per POST request on the bulk endpoint. That is useful for retroactive analysis: pull your last 30 days of login IPs, run them through the bulk endpoint, and see what your current scoring function would have caught.

Next steps

Start with logging-only mode. Apply the middleware to your login and signup routes, but only log the risk scores for a week before you enforce any blocking. Compare the scores against your existing fraud data to tune the thresholds. The defaults in the code above (ALLOW < 20, CHALLENGE < 50, BLOCK >= 50) are conservative. Your traffic will tell you whether to tighten or loosen them.

If you need the risk data without the API call on every request, the downloadable IP-to-ASN and IP Security databases let you run lookups locally. Latency drops to microseconds, but you take on the update cycle yourself.

Turn Any IP Address into Actionable Security Signals in JavaScript

Abdul Mateen — Thu, 23 Apr 2026 13:01:49 +0000

IP data is not just about location. It can also help you understand risk, detect suspicious traffic, and make smarter decisions in real time. In this guide, you will learn how to use IP intelligence to flag risky requests, enrich logs, and build simple security checks into your app using a single API.

Why IP intelligence matters for developers?

Every request hitting your app carries an IP address. Most apps ignore it beyond logging, but that IP can reveal useful signals such as:

Whether the request is coming from a VPN or proxy
If the IP is associated with known malicious activity
The ASN and ISP behind the request
Risk indicators you can use for rate limiting or blocking

Adding this layer helps you:

Reduce fraud and abuse
Improve login security
Filter bot traffic
Add context to analytics and logs

What you will build

By the end of this tutorial, you will have:

A JavaScript function that checks an IP for risk signals
A simple threat scoring logic for your app
A middleware style pattern for Node.js
A frontend example to display risk status

The API endpoint

We will use the following base endpoint:

https://api.ipgeolocation.io/v3/ipgeo

we will request security-related fields.

Step 1: Fetch IP security data

To access security details, a paid API key is required. You can view the pricing options here: IPGeolocation.io Pricing.

The Starter plan is a great option as it costs just $19/month and includes 150,000 credits, which should be enough for most basic use cases.

Here is a minimal JavaScript example:

async function checkIPSecurity(ip) {
  const API_KEY = 'YOUR_API_KEY';

  const res = await fetch(
    `https://api.ipgeolocation.io/v3/ipgeo?apiKey=${API_KEY}&ip=${ip}&include=security&fields=security`
  );

  const data = await res.json();
  return data.security;
}

// Example usage
checkIPSecurity('8.8.8.8').then(sec => {
  console.log('Is VPN:', sec.is_vpn);
  console.log('Is proxy:', sec.is_proxy);
  console.log('Is Tor:', sec.is_tor);
  console.log('Threat level:', sec.threat_score);
});

Example Response

{
  "security": {
    "is_vpn": false,
    "is_proxy": false,
    "is_tor": false,
    "threat_score": 12
  }
}

These fields give you quick signals without needing complex infrastructure.

Step 2: Create a simple threat scoring system

function evaluateRisk(security) {
  let risk = 'low';

  if (security.is_tor) return 'high';
  if (security.is_proxy || security.is_vpn) risk = 'medium';
  if (security.threat_score > 70) risk = 'high';

  return risk;
}

checkIPSecurity('8.8.8.8').then(sec => {
  const risk = evaluateRisk(sec);
  console.log('Risk level:', risk);
});

Step 3: Use it in a Node.js middleware

export async function securityMiddleware(req, res, next) {
  const ip =
    req.headers['x-forwarded-for']?.split(',')[0].trim() ||
    req.socket.remoteAddress;

  try {
    const response = await fetch(
      `https://api.ipgeolocation.io/v3/ipgeo?apiKey=${process.env.API_KEY}&ip=${ip}&include=security&fields=security`
    );

    const data = await response.json();
    const risk = evaluateRisk(data.security);

    if (risk === 'high') {
      return res.status(403).json({ error: 'Request blocked due to risk' });
    }

    req.riskLevel = risk;
    next();
  } catch (err) {
    next();
  }
}

Step 4: Add context to logs

console.log({
  ip,
  risk: req.riskLevel,
  route: req.originalUrl,
  timestamp: new Date().toISOString()
});

Step 5: Frontend risk indicator

function RiskBadge({ risk }) {
  const color =
    risk === 'high' ? 'red' :
    risk === 'medium' ? 'orange' : 'green';

  return (
    <span style={{ color }}>
      {risk.toUpperCase()}
    </span>
  );
}

Real-world use cases

Login protection

Flag suspicious logins and trigger additional verification

Rate limiting

Apply stricter limits for medium or high-risk IPs

Fraud detection

Block or review transactions from risky networks

Content protection

Restrict access to sensitive endpoints

Handling edge cases

VPN users

Not all VPN users are malicious. Treat them as medium risk instead of
blocking outright.

False positives

Always allow fallback paths, such as manual verification or email
confirmation.

API failure

Wrap calls in try-catch and default to safe behavior.

How to Detect a User's Country and Currency from the IP in JavaScript

Abdul Mateen — Thu, 23 Apr 2026 11:43:23 +0000

TL;DR: Use the IPGeolocation.io API to detect any visitor's country, currency code, currency symbol, and dial code from their IP address — no GPS prompt, no sign-in required. One API call returns everything. Free tier included.

What you'll build

By the end of this tutorial, you'll have a working JavaScript snippet that:

Detects the visitor's country and country flag from their IP address
Returns the local currency code, name, and symbol (e.g. EUR, Euro, €)
Pre-fills a checkout/signup form with country, dial code, and currency — automatically, on page load
Works in Vanilla JS, React, and Node.js

No browser permissions. No annoying "Allow location access" popups. Just a clean API call.

Why detect country and currency from IP?

When a user lands on your site, you already know roughly where they are — through their IP address. Most developers ignore this and make users manually select their country and currency, which:

Creates unnecessary friction at checkout
Increases form abandonment
Makes your site feel generic to international visitors

According to IPGeolocation.io's own data, displaying prices in a visitor's local currency alone can increase conversion rates by up to 40%. Personalizing content by location can improve engagement by up to 70%.

IP-based geolocation is non-intrusive — you're not asking for GPS coordinates or requiring any user interaction. It works silently in the background and simply makes the experience feel tailored.

The API: IPGeolocation.io

IPGeolocation.io is a developer-focused IP intelligence API that returns geolocation, currency, timezone, ASN, and security data for any IPv4 or IPv6 address. It's one of the few providers that includes:

Currency data (code, name, symbol) on the free plan
Country metadata (dial/calling code, TLD, spoken languages)
Country flag URLs and country emoji — ready to drop into UI
A JavaScript SDK available via npm and CDN

Free tier: 30,000 requests/month. No credit card required.

The endpoint we'll use: https://api.ipgeolocation.io/v3/ipgeo

Step 1: Get your free API key

Go to ipgeolocation.io and sign up
Copy your API key from the dashboard at https://app.ipgeolocation.io/dashboard

That's it. No waitlist, no credit card.

Step 2: Make your first API call (Vanilla JS)

The simplest possible call — detect the current visitor's IP automatically:

// Detects the visitor's own IP automatically when no `ip` param is passed
async function getUserGeoData() {
  const API_KEY = 'YOUR_API_KEY_HERE';

  const response = await fetch(
    `https://api.ipgeolocation.io/v3/ipgeo?apiKey=${API_KEY}&fields=location,currency,country_metadata`
  );

  const data = await response.json();
  return data;
}

getUserGeoData().then(data => {
  console.log('Country:', data.location.country_name);
  console.log('Currency code:', data.currency.code);     // e.g. "EUR"
  console.log('Currency symbol:', data.currency.symbol); // e.g. "€"
  console.log('Dial code:', data.country_metadata.calling_code); // e.g. "+49"
  console.log('Flag URL:', data.location.country_flag);
});

Sample API response

Here's what a real response looks like for a visitor from Germany:

{
  "ip": "85.212.44.10",
  "location": {
    "country_name": "Germany",
    "country_code2": "DE",
    "city": "Berlin",
    "state_prov": "Berlin",
    "country_flag": "https://ipgeolocation.io/static/flags/de_64.png",
    "country_emoji": "🇩🇪",
    "is_eu": true
  },
  "country_metadata": {
    "calling_code": "+49",
    "tld": ".de",
    "languages": ["de"]
  },
  "currency": {
    "code": "EUR",
    "name": "Euro",
    "symbol": "€"
  }
}

Notice how much you get in a single request: country, city, EU membership status, dial code, language, and full currency details.

Step 3: Auto-fill a checkout form

Now let's wire this into a real form. This pattern works for signup, checkout, lead gen — anything where you want to reduce friction for international users.

HTML

<form id="checkout-form">
  <label>Country
    <div style="display: flex; align-items: center; gap: 8px;">
      <img id="flag-img" src="" alt="" width="24" style="display:none;" />
      <input type="text" id="country-input" placeholder="Detecting..." />
    </div>
  </label>

  <label>Phone number
    <div style="display: flex; gap: 6px;">
      <input type="text" id="dial-code" style="width: 80px;" placeholder="+1" />
      <input type="tel" id="phone" placeholder="Your phone number" style="flex:1;" />
    </div>
  </label>

  <label>Preferred currency
    <input type="text" id="currency-input" placeholder="USD" />
  </label>
</form>

JavaScript — auto-fill on page load

async function prefillFormFromIP() {
  const API_KEY = 'YOUR_API_KEY_HERE';

  try {
    const res = await fetch(
      `https://api.ipgeolocation.io/v3/ipgeo?apiKey=${API_KEY}&fields=location,currency,country_metadata`
    );
    const data = await res.json();

    // Fill country field
    document.getElementById('country-input').value = data.location.country_name;

    // Show country flag
    const flagImg = document.getElementById('flag-img');
    flagImg.src = data.location.country_flag;
    flagImg.alt = data.location.country_emoji;
    flagImg.style.display = 'inline';

    // Fill dial code
    document.getElementById('dial-code').value = data.country_metadata.calling_code;

    // Fill currency
    const currencyDisplay = `${data.currency.code} (${data.currency.symbol})`;
    document.getElementById('currency-input').value = currencyDisplay;

  } catch (err) {
    console.error('Geolocation lookup failed:', err);
    // Gracefully fall back — leave fields blank for manual entry
  }
}

document.addEventListener('DOMContentLoaded', prefillFormFromIP);

UX tip: Always let the user override the pre-filled values. The goal is to reduce friction, not lock them in.

Step 4: Use the JavaScript SDK (optional but cleaner)

If you're working in a Node.js or bundled project, IPGeolocation.io has an official npm SDK that removes the need to hand-roll fetch calls.

Install

npm install ip-geolocation-api-javascript-sdk

Usage

import { IpGeolocationClient } from "ip-geolocation-api-javascript-sdk";

async function main() {
  const client = new IpGeolocationClient({
    apiKey: "YOUR_API_KEY",
  });

  try {
    const response = await client.lookupIpGeolocation({
      ip: "8.8.8.8",
    });

    console.log("Country:", response.data.location?.countryName); // "United States"
    console.log("City:", response.data.location?.city);
    console.log("Currency", response.data.currency?.code); // "USD"
  } finally {
    await client.close();
  }
}

main().catch((error) => {
  console.error(error);
});

The SDK handles authentication, error retries, and response parsing for you.

Step 5: Use it in React

Here's a clean React hook you can drop into any component:

import { useState, useEffect } from 'react';

function useIPGeo(apiKey) {
  const [geoData, setGeoData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchGeo = async () => {
      try {
        const res = await fetch(
          `https://api.ipgeolocation.io/v3/ipgeo?apiKey=${apiKey}&fields=location,currency,country_metadata`
        );
        const data = await res.json();
        setGeoData(data);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    };

    fetchGeo();
  }, [apiKey]);

  return { geoData, loading, error };
}

// Usage in a component
export default function CurrencyBanner({ apiKey }) {
  const { geoData, loading } = useIPGeo(apiKey);

  if (loading) return <p>Detecting your location...</p>;
  if (!geoData) return null;

  const { currency, location, country_metadata } = geoData;

  return (
    <div className="geo-banner">
      <img
        src={location.country_flag}
        alt={location.country_name}
        width={20}
      />
      <span>
        Showing prices in <strong>{currency.name}</strong> ({currency.symbol})
        for {location.country_name}
      </span>
    </div>
  );
}

What fields does the API return?

Here's a quick reference for the fields most useful in localization and checkout flows:

Field path	Example value	Use case
`location.country_name`	`"Germany"`	Display name, form pre-fill
`location.country_code2`	`"DE"`	Passing to payment providers
`location.country_flag`	URL to PNG	Flag icon in UI
`location.country_emoji`	`"🇩🇪"`	Inline emoji flag
`location.is_eu`	`true`	Trigger GDPR consent banner
`currency.code`	`"EUR"`	ISO 4217 currency for Stripe/payment APIs
`currency.name`	`"Euro"`	Display label
`currency.symbol`	`"€"`	Price display
`country_metadata.calling_code`	`"+49"`	Phone number dial code
`country_metadata.languages`	`["de"]`	Auto-select UI language

Handling edge cases

What if the user is on a VPN?

If a user is tunneling through a VPN, the API will return the VPN server's country, not the user's real country. For checkout forms, this is usually fine — the user chose to appear in that country. If it matters for your use case (e.g., tax calculation), you can enable IPGeolocation.io's Security module alongside this call to detect VPN/proxy usage and prompt the user to confirm their location.

What about server-side rendering (Next.js)?

On the server, you have access to the real IP via request headers (x-forwarded-for or req.socket.remoteAddress). Pass that IP explicitly to the API:

// pages/api/geo.js (Next.js API route)
export default async function handler(req, res) {
  const ip =
    req.headers['x-forwarded-for']?.split(',')[0].trim() ||
    req.socket.remoteAddress;

  const API_KEY = process.env.IPGEO_API_KEY;
  const response = await fetch(
    `https://api.ipgeolocation.io/v3/ipgeo?apiKey=${API_KEY}&ip=${ip}&fields=location,currency,country_metadata`
  );

  const data = await response.json();
  res.status(200).json(data);
}

Security note: Keep your API key in environment variables (process.env.IPGEO_API_KEY). Never expose it in client-side JavaScript if you're on a paid plan.

Free tier limits and when to upgrade

Plan	Requests/month	Currency data	Security data
Free	30,000	✅	❌
Paid	150,000+	✅	❌

For most personal projects and small SaaS apps, the free tier is more than enough. Once you need VPN/proxy detection, threat scoring, or higher volume, upgrade to the Paid plan.

Frequently asked questions

Does IP geolocation work for IPv6?
Yes. IPGeolocation.io supports both IPv4 and IPv6 lookups natively. The API endpoint and response format are identical.

How accurate is IP-based country detection?
Country-level accuracy is typically above 99% for most IP ranges. City-level accuracy varies more. For currency and country pre-filling, country-level is all you need.

Can I use this on the frontend without an API key?
Yes — IPGeolocation.io supports keyless authentication via request origin (CORS allowlisting). You add your domain to the dashboard and the API authenticates requests from that domain automatically. This is ideal for frontend-only projects.

Does using IP geolocation require GDPR consent?
Detecting a country from an IP address for UX purposes (form pre-fill, currency display) is generally considered legitimate interest under GDPR — it doesn't involve storing or tracking personal data. Always consult your legal team for your specific use case.

What happens if the API is down or slow?
Always wrap the API call in a try/catch and provide a graceful fallback (leave fields empty, default to USD, etc.). IPGeolocation.io runs on Cloudflare's global network with a 99.99% uptime SLA on paid plans.

Summary

Here's what we covered:

Why detecting country and currency from IP improves conversion and UX
How to use the IPGeolocation.io /v3/ipgeo endpoint to retrieve country, currency, flag, and dial code in one call
A Vanilla JS snippet to auto-fill a checkout form on page load
The npm SDK for Node.js and bundled projects
A React hook (useIPGeo) ready to drop into any component
A Next.js API route pattern for server-side IP resolution
Edge cases: VPN detection, SSR, GDPR, and API key security

The full API response gives you everything you need for a localized, frictionless experience — with zero popups, zero GPS requests, and zero user interaction required.

What's next?

Localize your full UI: Use location.is_eu to trigger GDPR banners, country_metadata.languages to switch UI language automatically
Go offline: For high-traffic apps, IPGeolocation.io offers downloadable IP Geolocation Databases (MMDB, CSV, JSON) for sub-millisecond local lookups