Datacenter IP API

You need a reliable way to tell if an incoming request is originating from a datacenter IP so you can apply the right trust and friction controls. By the end of this guide, you will be able to call ipXapi’s datacenter IP check using the fraud-score endpoint, authenticate with a bearer token, parse the datacenter.is_datacenter flag, and wire the result into your application flow.

What you will build

This guide focuses on a single job: programmatically determine whether an IP is from a datacenter. You will:

• Call the ipXapi Datacenter IP lookup via the /api/fraud-score path.
• Authenticate with an Authorization: Bearer token.
• Parse the JSON response and specifically the datacenter.is_datacenter boolean.
• Handle practical concerns like timeouts, retries, and minimal caching.

Endpoint and authentication

ipXapi exposes a Datacenter IP lookup via the following path:

• HTTP method: GET
• Path: /api/fraud-score
• Query parameter: ip (the IP address you are checking)
• Auth: Authorization: Bearer YOUR_API_KEY

Use the bearer token in the Authorization header for every request. Keep the token server-side only. For client apps, proxy calls through your backend to avoid exposing credentials.

Reference: the Documentation covers the full envelope of fields and integration notes.

Pricing, trial, and environments

The Basic plan is $29.99/month. There is a trial for 7 days or 50 requests. To get started, create an account and obtain your API key from the dashboard, then plug that key into your Authorization header.

Management Control Plane (MCP) is available at MCP. Use it to manage keys and observe your usage. Production API requests use the ipXapi base domain shown in the examples below.

Quick test with cURL

Below is the official cURL example against the documented fixture IP. Copy, paste, and run it after replacing the authorization token with your own. This confirms network connectivity and your key’s permissions.

curl "https://ipxapi.com/api/fraud-score?ip=8.8.8.8" -H "Accept: application/json" -H "Authorization: Bearer YOUR_KEY"

Understand the response

This is the official JSON sample for the same IP. Your live responses may vary. Do not assume the sample values will match your runtime values—treat them only as a schema reference.

{
"ip": "8.8.8.8",
"fraud_score": 0,
"risk_level": "low",
"risk_label": "Low Risk",
"is_high_risk": false,
"operator": {
"organization": "Level 3",
"isp": "Google LLC",
"asn": "15169",
"hostname": "dns.google"
},
"location": {
"country_code": "US",
"city": "Mountain View"
},
"datacenter": {
"is_datacenter": true
}
}

Key fields you will use:

• ip: The IP that was evaluated.
• datacenter.is_datacenter: Boolean you will branch on to decide whether to treat the IP as coming from a datacenter.
• fraud_score, risk_level, risk_label, is_high_risk: Optional risk indicators you can log or use to refine rules.
• operator and location: Optional context for analytics and auditing.

Integrate in application code

The example below shows a minimal, production-ready flow to call the endpoint, parse datacenter.is_datacenter, and surface a decision for your app logic. It includes timeouts, a single retry on transient failures, and safe JSON parsing.

JavaScript (Node.js) example

import https from "node:https";

function fetchDatacenterFlag(ip) {
const url = new URL("https://ipxapi.com/api/fraud-score");
url.searchParams.set("ip", ip);

const headers = {
"Accept": "application/json",
"Authorization": "Bearer YOUR_API_KEY"
};

return new Promise((resolve, reject) => {
const req = https.request(
url,
{ method: "GET", headers, timeout: 6000 },
(res) => {
let data = "";
res.on("data", (chunk) => (data += chunk));
res.on("end", () => {
if (res.statusCode < 200 || res.statusCode >= 300) {
return reject(new Error(`ipXapi HTTP ${res.statusCode}: ${data}`));
}
try {
const json = JSON.parse(data);
const isDc = Boolean(json?.datacenter?.is_datacenter);
resolve({
ip: json?.ip,
isDatacenter: isDc,
riskLabel: json?.risk_label,
riskLevel: json?.risk_level,
fraudScore: json?.fraud_score
});
} catch (e) {
reject(new Error(`Invalid JSON from ipXapi: ${e.message}`));
}
});
}
);

req.on("error", (err) => reject(err));
req.on("timeout", () => {
req.destroy(new Error("ipXapi request timed out"));
});
req.end();
});
}

// Simple retry wrapper for one transient failure
async function getDatacenterDecision(ip) {
try {
return await fetchDatacenterFlag(ip);
} catch (err) {
// Retry once on network-type errors
if (/(timed out|ECONNRESET|EAI_AGAIN|ENOTFOUND)/i.test(String(err.message))) {
return await fetchDatacenterFlag(ip);
}
throw err;
}
}

// Example usage:
// Call with the documented fixture IP. Replace with runtime IPs in your app.
getDatacenterDecision("8.8.8.8")
.then((res) => {
if (res.isDatacenter) {
// Gate login with MFA, add captcha, or limit actions
console.log(`IP ${res.ip} is a datacenter. Applying stricter controls.`);
} else {
console.log(`IP ${res.ip} is residential or not flagged as datacenter.`);
}
// Optional: log risk context for observability
console.log({
fraudScore: res.fraudScore,
riskLevel: res.riskLevel,
riskLabel: res.riskLabel
});
})
.catch((err) => {
// Fallback behavior if the API call fails
console.error("ipXapi lookup failed:", err.message);
// Choose a safe default: allow with monitoring or apply mild friction
});

Decisioning patterns with datacenter.is_datacenter

The datacenter.is_datacenter boolean is the primary decision flag. A common pattern is to gate sensitive actions when true, while still allowing read-only behavior. For example, require step-up verification for new device sign-ins or when the action is high value (account changes, payments, credential updates).

If you already run fraud scoring, combine datacenter.is_datacenter with the risk fields in the same response, logging those values for forensics. Avoid hard blocks until you have enough telemetry to validate the rule’s impact.

Timeouts, retries, and client behavior

• Timeouts: Set a short, explicit timeout on HTTP requests (for example, 6 seconds in the sample). If your app latency budget is tighter, choose a lower value and implement graceful fallbacks.
• Retries: Retry only once on transient network errors. Do not retry on 4xx responses.
• Concurrency: For high-throughput services, reuse HTTP connections (keep-alive) and cap concurrency to avoid head-of-line blocking.

Caching and consistency

IP properties are not static, but they do not typically change minute-to-minute for most IPs. Implement a short-lived cache keyed by IP to cap request volume and reduce latency. Cache invalidation should be aggressive in interactive flows: keep TTLs short and be ready to refresh on suspicious activity signals.

Do not cache errors. If a lookup fails, let the calling layer decide a safe default behavior (e.g., allow with monitoring or apply mild friction), and re-attempt on the next action.

Logging and observability

At minimum, log the following for every decision:

• ip
• datacenter.is_datacenter
• Optionally, fraud_score, risk_level, risk_label
• Latency and status of the upstream call

Redact tokens and any secrets in logs. Use unique request IDs to correlate upstream calls with user actions for debugging.

Testing with a known fixture

To verify your parser and branching logic, use the documented fixture IP 8.8.8.8 during development. Your unit tests should assert that the code can safely access nested properties and handle missing fields without throwing. Integration tests should include at least one run where datacenter.is_datacenter is true and one where it is false. When running against live data, remember that flags can change; do not hard-code expectations for any specific IP outside test fixtures.

Security considerations

• Do not expose your bearer token to clients; proxy via your backend.
• Validate and sanitize request inputs before passing them to the API (e.g., ensure ip is a valid IPv4 or IPv6 string).
• Enforce HTTPS everywhere and verify you are connecting to the expected domain.

Operational tips

• Backoff on repeated network errors to avoid cascading failures during provider or network incidents.
• Graceful degradation: if the lookup is unavailable, proceed with your lowest-risk default while flagging the session for review.
• Configuration: make the endpoint URL and timeouts configurable for faster incident response.

Going live

Before rolling out to 100% of traffic:

• Run in shadow mode for a short period: capture datacenter.is_datacenter decisions without enforcing new rules.
• Compare outcomes and error rates to establish a baseline.
• Roll out progressively and add dashboards for request rate, latency, error codes, and decision distributions.

Frequently asked questions

How do I authenticate to the Datacenter IP API?
Send Authorization: Bearer YOUR_API_KEY with every request.

Which endpoint returns the datacenter flag?
Use the GET path /api/fraud-score with the ip query parameter.

Which response field tells me if the IP is a datacenter?
Check datacenter.is_datacenter (boolean) in the JSON response.

Is there a free trial?
Yes. The trial is 7 days or 50 requests.

What is the base URL for management?
Use MCP for management and usage visibility.

Next steps

Create your account, get your API key, and wire the datacenter.is_datacenter check into your signin and high-value action flows. Start here: Register. For additional parameters and field references, see the Documentation.