IP Usage Type API: Hosting Class From an Address

You need to decide whether an incoming IP address is a residential ISP, a hosting provider, or a CDN before you treat it like a household user. By the end of this article, you’ll be able to query ipXapi’s IP Usage Type API, read the usage_type for an address, and ship production logic that branches on usage_type together with is_whitelisted.

Why IP usage type matters in real apps

Sign-in risk scoring, checkout fraud checks, rate limiting, geo personalization, and content blocking all work better when you know how an IP is used. A CDN or hosting provider usually behaves differently from a last-mile ISP. If you treat a CDN like a household, you might block legitimate cache-warmer traffic or break public DNS resolvers. If you treat all hosting as abusive, you’ll block legitimate corporate NATs. The fix: query usage_type and combine it with a whitelist flag.

ipXapi exposes this as a single field (usage_type) on a lightweight endpoint so you can make the decision right where you accept traffic, sync logs, or adjudicate payments.

Endpoint, authentication, and pricing at a glance

Endpoint: GET https://ipxapi.com/api/abuse-check?ip=

• Authentication: Bearer token in the Authorization header.
• Field of interest: usage_type (e.g., Content Delivery Network, ISP, hosting provider), plus is_whitelisted for exceptions.
• Basic plan: $29.99/mo with a 7-day trial or 50 requests to get started.

Sign up and obtain your key using Register. You can find additional reference material and endpoints in the Documentation, and manage your account in MCP.

Quick-start with the official example

The official quick-start uses the Google Public DNS IP (8.8.8.8). It demonstrates how a non-household address can be classified yet still be safe to allow due to whitelisting.

Request

curl 'https://ipxapi.com/api/abuse-check?ip=8.8.8.8' \
  -H 'Accept: application/json' \
  -H 'Authorization: Bearer YOUR_KEY' 

Response

{
  "ip": "8.8.8.8",
  "isp": "Google LLC",
  "usage_type": "Content Delivery Network",
  "hostname": "dns.google",
  "domain": "google.com",
  "is_listed": false,
  "is_whitelisted": true
}

What the response tells you:

• usage_type: How the address is used (for the official sample IP, it’s “Content Delivery Network”). This answers the core question: hosting, ISP, CDN, etc.
• is_whitelisted: A boolean you should check alongside usage_type. Some non-household IPs (e.g., public DNS or well-known CDN edges) are explicitly whitelisted.

Important: Do not treat usage_type alone as abuse. The sample shows Google Public DNS recognized as a CDN-class address and whitelisted, meaning your application should permit it if your policy allows whitelisted infrastructure.

Call the API from your stack

You can invoke the same endpoint with your own key. The following curl example and a minimal Python snippet both query the same IP and consume usage_type and is_whitelisted.

Production-ready curl you can paste

curl -s "https://ipxapi.com/api/abuse-check?ip=8.8.8.8" \
  -H "Authorization: Bearer YOUR_API_KEY"

Minimal Python example

import os
import requests

API_KEY = os.environ.get("IPXAPI_KEY", "YOUR_API_KEY")
ip = "8.8.8.8"  # replace with the address you want to check

url = f"https://ipxapi.com/api/abuse-check?ip={ip}"
headers = {"Authorization": f"Bearer {API_KEY}"}

try:
    r = requests.get(url, headers=headers, timeout=5)
    # If the service uses non-200 codes on errors, this will surface them:
    r.raise_for_status()
    data = r.json()

    # Prefer explicit keys when present; handle missing values defensively.
    usage_type = data.get("usage_type")
    is_whitelisted = data.get("is_whitelisted")

    # Example branching policy:
    if is_whitelisted is True:
        decision = "allow"
    elif usage_type is None:
        decision = "review"  # unknown usage, apply conservative fallback
    elif usage_type in ("Content Delivery Network", "Hosting", "Data Center"):
        decision = "additional_checks"
    else:
        decision = "allow"

    print({
        "ip": ip,
        "usage_type": usage_type,
        "is_whitelisted": is_whitelisted,
        "decision": decision
    })

except requests.HTTPError as e:
    # If the API signals an application error with JSON body (e.g., success=false),
    # you can read it here if provided; otherwise log and back off.
    print({"error": "http_error", "status": r.status_code, "detail": str(e)})
except requests.RequestException as e:
    # Network timeouts, DNS errors, etc.
    print({"error": "network_error", "detail": str(e)})

Replace 8.8.8.8 with any target IP you need to classify. The title of this post focuses on “Hosting Class From an Address.” The official sample IP is a public DNS service classified as a CDN. Your own calls use the same endpoint and fields; you’ll simply pass your target IP instead of 8.8.8.8 and read usage_type to determine whether it’s hosting, ISP, or CDN.

Make decisions with usage_type and is_whitelisted

Ship policies that use both fields. Examples:

• Login security: If usage_type is hosting or CDN and is_whitelisted is false, step up authentication (e.g., require MFA) instead of outright blocking.
• Checkout risk: Hosting without whitelisting → require additional verification; CDN with whitelisting → allow but throttle if necessary.
• Rate limiting: Treat whitelisted infrastructure as shared egress and enforce per-account rather than per-IP limits.

Remember, Google Public DNS (as used in the official example) is a CDN-class address and whitelisted. Your logic should not penalize it just because the usage_type isn’t ISP; the whitelist is the override signal that this is expected and permitted traffic.

Error handling, unknowns, and resilience

Your code should anticipate three states: a successful classification, a structured application error, and transport failures.

• Successful classification: usage_type is present. Use it with is_whitelisted to reach a decision.
• Application error: If the response includes a JSON flag (such as success=false) or a message, honor it and fail closed or soft, depending on your system’s tolerance. Because response schemas can evolve, check for the presence of keys before using them.
• Transport failures: On timeouts or 5xx, backoff and retry. If your UX can’t wait, use cached results (see caching below) or a conservative fallback policy.

Defensive parsing tips:

• Treat missing values as unknown: if usage_type is absent or null, route to a “review” or “limited” path rather than blocking everything.
• Do not assume you will always receive a particular set of fields. Use .get() in tolerant languages and schema validation where strictness helps.

Caching and freshness

IP usage types are relatively stable compared to per-request signals. Caching saves latency and request volume:

• Cache by IP address. Include your own fetched_at in UTC in the cache value so you can age entries predictably.
• Choose a TTL that matches your risk tolerance. Many teams start with hours to days for infrastructure IPs and shorter windows if your decisions are safety-critical.
• Pre-warm your cache for high-traffic IPs (e.g., your CDN partners or public DNS resolvers) during startup to avoid cold paths.

Because responses may not include timestamps, store metadata alongside the value you cache (e.g., when you fetched it and the decision you derived) so you can re-evaluate periodically.

Going live in four steps

1. Register: Create your account at Register and start on the Basic plan ($29.99/mo) with a 7-day trial or 50 requests.
2. Copy the Bearer token: Store it securely (environment variable or secrets manager).
3. Query the endpoint: GET /api/abuse-check?ip= for each IP you want to classify.
4. Branch on the result: Use usage_type together with is_whitelisted in your decision tree.

Implementation checklist

• Transport: Always send Authorization: Bearer YOUR_API_KEY. Use HTTPS.
• Timeouts: Keep client timeouts short (e.g., a few seconds) and implement retries with backoff.
• Parsing: Read usage_type and is_whitelisted if present. Handle success=false and missing values gracefully.
• Policy: Do not treat usage_type alone as abuse. Check is_whitelisted and fallbacks.
• Observability: Log the IP, usage_type, is_whitelisted, decision, and response status for audits.
• Caching: Introduce an IP cache with a TTL that fits your risk and traffic profile.

Troubleshooting common scenarios

• All traffic looks like hosting: Confirm you’re passing the correct client IP. If you’re behind a reverse proxy or CDN, you may be querying your edge’s IP instead of the origin client. Make sure you extract the client address correctly before calling the API.
• Your app blocks Google Public DNS: Integrate is_whitelisted into your checks. The example 8.8.8.8 is whitelisted; your decision logic should respect it.
• Your dev environment intermittently fails: Add retries with jitter and verify your Bearer token is valid and present.
• You need to audit decisions later: Persist both the raw fields (usage_type, is_whitelisted) and your computed decision per request.

Where to manage and learn more

Manage keys, observe usage, and handle team access in MCP. For field definitions, request examples, and broader capabilities, read the Documentation. When you’re ready to use your own key and start reading usage_type, head to Register.

FAQ

Which field tells me how an IP is used?
Read usage_type from GET /api/abuse-check?ip= with Bearer authentication.

Should I block all hosting or CDN IPs?
No. Combine usage_type with is_whitelisted. Some infrastructure IPs are trusted and explicitly whitelisted.

What happens if the response omits a field I expect?
Treat missing values as unknown and route to a safe fallback (e.g., review). Check for a structured error (e.g., a success flag) if provided and handle according to your policy.

How do I authenticate?
Send your key as an Authorization: Bearer header. Obtain the key from Register.

Is there a free way to try this?
Yes. The Basic plan includes a 7-day trial or 50 requests so you can integrate and test.

Classify any IP’s hosting class quickly: register for an API key, call /api/abuse-check?ip=, and branch on usage_type with is_whitelisted. Start now on the trial via Register, and keep the Documentation and MCP handy as you ship to production.