Risk-Based Rate Limiting with IP Intelligence in 2026: Route Budgets, ASN Clusters, and Proxy Review

The workflow problem: volume without context

Rate limiting usually starts with a number: 100 requests per minute, 10 login attempts, 5 checkout retries, or 1,000 API calls per hour. Those numbers are useful, but they are blind. A burst from a known corporate ASN on a public documentation page is different from the same burst on a password reset route. A country mismatch on a content page might be harmless. The same mismatch on checkout, paired with a new ASN and repeated payment attempts, deserves a different action.

The goal is not to block more traffic. The goal is to spend friction where it protects the business. Risk-based rate limiting turns IP intelligence into route-specific budgets. Low-risk traffic gets sampled or observed. Sensitive routes can slow down, step up, or review. Bulk analytics and suspicious traffic investigations can use batch enrichment instead of calling the API on every request.

This guide does not claim a native WAF, CDN, Cloudflare, Fastly, Akamai, AWS WAF, or API gateway connector. Unless that connector is verified in your own environment, describe this as API-based custom automation. The verified product surface is the lookup API, documented response fields, live demo, pricing and API key surfaces, and site-positioned privacy and fraud signals.

What current market research says

Current competitor pages show why this is a real architecture topic. IPinfo positions privacy detection around VPN, proxy, Tor, relay, hosting, confidence, and daily updates. MaxMind documents anonymous IP flags for VPN, hosting, public proxy, Tor exit nodes, and residential proxy records. IPQualityScore describes proxy detection with fraud score, user context, Tor, VPN, bot, and real-time prevention language. ipgeolocation.io packages security, VPN, proxy, Tor, batch lookup, ASN, company, accuracy radius, and confidence fields across paid surfaces.

Buyers are comparing more than geolocation. They are comparing how a service helps them decide when to observe, throttle, challenge, review, or block. That maps directly to route budgets: different routes carry different business risk, and each route should use IP evidence differently.

A practical model: route budgets plus network evidence

A route budget is a threshold tied to what the route does. Public read routes can tolerate more requests and broader sampling. Signup and login routes need stricter budgets because attackers can create accounts, test credentials, or trigger email and SMS costs. Checkout routes need extra care because payment abuse creates direct loss. Write-heavy APIs need limits that protect infrastructure and customer data.

IP intelligence adds grouping and explanation. ASN can show whether traffic clusters around one network. Organization and AS organization help analysts distinguish consumer ISPs, cloud providers, corporate gateways, and infrastructure providers. Country and registered country can reveal regional inconsistencies. Accuracy radius keeps teams from treating city-level output as perfect. Proxy, VPN, and Tor signals, when verified in your response or plan, help separate ordinary browsing from traffic that might be hiding context.

Step-by-step implementation workflow

1. Classify routes by business risk

Put every route into a small set of classes: public read, signup, login, checkout, account change, API write, or backoffice. Do not start with per-route thresholds for everything. Start with classes, then specialize only when the data shows a route needs its own rule.

2. Decide which routes deserve live enrichment

Live IP lookup belongs on sensitive routes where the result affects an immediate decision. Login, checkout, promotion redemption, password reset, and write-heavy API actions are common candidates. Public browsing and analytics can often use sampling, caching, or offline enrichment.

3. Build limit keys from route class and network context

A pure IP key works for simple throttling, but it misses network clusters. Grouping by route class and ASN can reveal high-volume traffic from one infrastructure network without overreacting to each individual IP. Keep an escape hatch for known corporate networks, partner systems, and documented customer gateways.

4. Use actions, not only allow or block

Good rate limiting has more than two outcomes. Public routes can sample. Signup can slow down. Login can step up. Checkout can review. API writes can return retry guidance. Blocking should be reserved for clear policy violations, abuse bursts, or previously validated bad patterns.

5. Cache carefully

Hot-path lookups should be cached briefly to control latency and credit use, but not so long that fraud rules operate on stale context. The cache TTL for login and checkout should usually be shorter than a warehouse or analytics enrichment TTL. If a lookup fails, sensitive routes should degrade to step-up or review instead of exposing a generic error.

6. Review outcomes with support and fraud teams

Rate-limit rules create user experience. Review sampled actions, step-ups, and blocks weekly after launch. Look for support tickets from legitimate travelers, corporate VPN users, mobile networks, and shared gateways. Tune route budgets with evidence instead of making one global threshold stricter.

Technical implementation examples

Start by verifying the lookup response shape against the public API.

curl -X GET "https://api.ip-info.app/v1-get-ip-details?ip=1.1.1.1" \
  -H "accept: application/json" \
  -H "x-api-key: $IP_INFO_API_KEY"

A short-lived lookup cache keeps hot-path decisions from repeating identical calls while traffic is passing through a route window.

const lookupCache = new Map<string, { expiresAt: number; value: IpDetails }>();

async function lookupIpForRateLimit(ip: string): Promise<IpDetails> {
  const cached = lookupCache.get(ip);
  if (cached && cached.expiresAt > Date.now()) {
    return cached.value;
  }

  const url = new URL('https://api.ip-info.app/v1-get-ip-details');
  url.searchParams.set('ip', ip);

  const response = await fetch(url, {
    headers: {
      accept: 'application/json',
      'x-api-key': process.env.IP_INFO_API_KEY ?? '',
    },
    cache: 'no-store',
  });

  if (!response.ok) {
    throw new Error('IP lookup failed');
  }

  const value = (await response.json()) as IpDetails;
  lookupCache.set(ip, { expiresAt: Date.now() + 5 * 60 * 1000, value });
  return value;
}

The policy example below builds a route-class budget, groups by ASN when available, and produces actions a gateway or application can enforce. It uses only fields verified in the public schema. Add proxy, VPN, Tor, or threat fields only after confirming the response names in your own plan.

type IpDetails = {
  ip: string;
  countryCode?: string;
  registeredCountryCode?: string;
  asn?: number;
  aso?: string;
  organization?: string;
  city?: {
    accuracyRadius?: number;
    timeZone?: string;
  };
};

type RouteClass = 'public_read' | 'signup' | 'login' | 'checkout' | 'api_write';
type RateAction = 'allow' | 'sample' | 'slow_down' | 'step_up' | 'block';

interface RequestContext {
  ip: string;
  route: string;
  routeClass: RouteClass;
  method: 'GET' | 'POST' | 'PUT' | 'PATCH' | 'DELETE';
  requestsInWindow: number;
  knownGoodAsns: number[];
}

interface RateDecision {
  action: RateAction;
  limitKey: string;
  reasons: string[];
  evidence: {
    ip: string;
    routeClass: RouteClass;
    countryCode?: string;
    registeredCountryCode?: string;
    asn?: number;
    organization?: string;
    accuracyRadius?: number;
  };
}

const routeBudgets: Record<RouteClass, number> = {
  public_read: 240,
  signup: 20,
  login: 30,
  checkout: 15,
  api_write: 60,
};

function buildLimitKey(details: IpDetails, context: RequestContext) {
  if (details.asn) {
    return `${context.routeClass}:asn:${details.asn}`;
  }

  return `${context.routeClass}:ip:${context.ip}`;
}

export function chooseRateLimitAction(details: IpDetails, context: RequestContext): RateDecision {
  const reasons: string[] = [];
  const budget = routeBudgets[context.routeClass];
  const countryMismatch =
    Boolean(details.countryCode) &&
    Boolean(details.registeredCountryCode) &&
    details.countryCode !== details.registeredCountryCode;
  const knownGoodNetwork = details.asn ? context.knownGoodAsns.includes(details.asn) : false;

  if (context.requestsInWindow > budget) {
    reasons.push('route_budget_exceeded');
  }

  if (countryMismatch) {
    reasons.push('country_registration_mismatch');
  }

  if ((details.city?.accuracyRadius ?? 0) > 500) {
    reasons.push('broad_location_radius');
  }

  if (details.asn && !knownGoodNetwork && context.requestsInWindow > budget / 2) {
    reasons.push('unrecognized_asn_volume');
  }

  const sensitiveRoute = context.routeClass === 'login' || context.routeClass === 'checkout';
  const action: RateAction =
    reasons.includes('route_budget_exceeded') && sensitiveRoute && countryMismatch
      ? 'step_up'
      : reasons.includes('route_budget_exceeded') && context.method !== 'GET'
        ? 'slow_down'
        : reasons.includes('route_budget_exceeded')
          ? 'sample'
          : 'allow';

  return {
    action,
    limitKey: buildLimitKey(details, context),
    reasons,
    evidence: {
      ip: details.ip,
      routeClass: context.routeClass,
      countryCode: details.countryCode,
      registeredCountryCode: details.registeredCountryCode,
      asn: details.asn,
      organization: details.organization ?? details.aso,
      accuracyRadius: details.city?.accuracyRadius,
    },
  };
}

Decision matrix for route-level policy

How this differs from suspicious traffic analysis

Suspicious traffic analysis starts after something looks wrong: a spike, a WAF alert, a chargeback burst, or an analytics anomaly. Risk-based rate limiting is preventive. It puts the action ladder in front of sensitive routes so the system can slow down account creation, challenge risky logins, or review checkout attempts before a spike becomes an incident.

The two workflows still share evidence. ASN clusters help both. Country and registered country mismatches help both. Proxy, VPN, Tor, and accuracy-radius context help both. The difference is timing and blast radius. Rate limiting should be narrow, route-aware, and reversible. Incident analysis can be broader, slower, and more exploratory.

Measurement that avoids false confidence

Track more than blocked request count. Measure step-up rate, support tickets, successful legitimate retries, conversion impact, chargeback change, duplicate signup reduction, and API spend by route class. A rule that blocks many requests may be valuable, or it may be noisy. A rule that reduces checkout abuse while keeping good users moving is much easier to defend.

Also log why each action happened. A reason code such as route_budget_exceeded tells a different story from country_registration_mismatch or unrecognized_asn_volume. Those reason codes help fraud teams tune rules, support teams explain challenges, and finance teams connect lookup volume to business outcomes.

FAQ

Internal links for implementation planning

Test a route-level lookup in the live demo, confirm response fields in the OpenAPI reference, and review packaging on the pricing page. For adjacent work, read the suspicious traffic analysis guide, ASN and ISP workflow guide, explainable risk decisions guide, and lookup cost governance guide.