IP Proxy Detection API: is_proxy From an Address

You need to decide, programmatically, whether an incoming IP is using a proxy. By the end of this guide you will call ipXapi’s single geolocation endpoint and read security.is_proxy (plus related flags) to make an allow/deny or step-up decision in your app.

One endpoint, geolocation + proxy flags

ipXapi returns proxy detection on the same geolocation path; there is no separate proxy host. You call GET /api/ip with an IP address and Bearer authorization, then read security.is_proxy. The same response also includes related booleans such as security.is_vpn and security.is_cloud_provider.

The official documentation’s sample request uses the IP 148.105.12.120 (MailChimp). Treat it as a product example only: security signals are live and can change over time, and it is not your current IP.

If you need reference docs while you integrate, open the Documentation. For managed connectivity details, see MCP.

When to check security.is_proxy

• Account creation and logins: decide whether to require MFA or add friction.
• Transactions and content posting: score risk if the IP is a proxy or VPN.
• Rate limiting and abuse prevention: treat proxy or cloud-originated traffic differently.
• Compliance and geo-restrictions: combine country with proxy/vpn flags to harden checks.

Make the request

Send a GET to /api/ip with the ip query parameter and your Bearer key. Here is the official request using the documentation IP. Replace YOUR_API_KEY with your credential, and replace the ip value with the address you want to evaluate.

Do not treat the sample IP as your own; it is provided to demonstrate the shape of the response.

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

Understand the response

This is the official product sample response for the same call. Values shown here can change at any time in real traffic; write your code to handle booleans flipping between true and false and fields that may be absent.

{
  "status": "success",
  "country": "United States",
  "countryCode": "US",
  "city": "Mountain View",
  "query": "148.105.12.120",
  "security": {
    "is_proxy": false,
    "is_vpn": false,
    "is_cloud_provider": true
  }
}

What you will actually read from this JSON for proxy detection:

• security.is_proxy: boolean. The primary flag indicating whether the IP is identified as a proxy.
• security.is_vpn: boolean. Whether the IP is associated with VPN usage.
• security.is_cloud_provider: boolean. Whether the IP is from a cloud provider range (often used for automation or hosting).

Interpretation tips:

• Use security.is_proxy as your main allow/step-up/deny signal for proxy detection.
• Combine security.is_vpn and security.is_cloud_provider with your business logic. For example, you might allow cloud-originated health checks but step-up user sessions from VPNs.
• Do not hardcode assumptions from the sample JSON; these signals are live and can vary by time and address.

Quickstart in JavaScript

This example calls the same endpoint and inspects the security flags. It uses the same IP as the documentation; substitute your target IP at runtime.

async function checkIpProxy(ip) {
  const url = new URL('/api/ip', 'https://ipxapi.com');
  url.searchParams.set('ip', ip);

  const res = await fetch(url.toString(), {
    method: 'GET',
    headers: {
      'Authorization': 'Bearer YOUR_API_KEY',
      'Accept': 'application/json'
    }
  });

  // Prefer HTTP status to detect transport errors.
  if (!res.ok) {
    // If the body includes error info, surface it; otherwise throw a generic message.
    let msg = `HTTP ${res.status}`;
    try {
      const err = await res.json();
      if (err && typeof err === 'object') msg += `: ${JSON.stringify(err)}`;
    } catch (_) {}
    throw new Error(`ipXapi request failed: ${msg}`);
  }

  const data = await res.json();

  // security may be missing; guard accordingly.
  const security = (data && data.security) || {};
  const isProxy = security.is_proxy === true;
  const isVpn = security.is_vpn === true;
  const isCloud = security.is_cloud_provider === true;

  return { isProxy, isVpn, isCloud, raw: data };
}

// Example usage with the documentation IP:
checkIpProxy('148.105.12.120')
  .then(({ isProxy, isVpn, isCloud }) => {
    console.log('is_proxy:', isProxy);
    console.log('is_vpn:', isVpn);
    console.log('is_cloud_provider:', isCloud);
  })
  .catch(err => {
    console.error('Lookup failed:', err);
  });

Error handling, missing values, and reliability

Transport errors: check the HTTP status first. Non-2xx responses indicate a transport or authorization failure; handle them with retries or fallbacks depending on your needs.

API-level failures: if the JSON includes a general success indicator or error object, read that to branch your logic. If there is no such field, rely on HTTP status and the presence of expected fields.

Missing fields: security may not always be present. Use defensive access (e.g., data.security?.is_proxy) and default to a safe behavior when a value is missing.

Caching: proxy/VPN/cloud flags can change. If you cache, do so for a short period and revalidate frequently for active sessions or high-risk actions.

Timezones and timestamps: if your workflow stores timestamps for audits, normalize them to UTC on write and convert for display later.

Throughput: batch lookups where possible to reduce round trips, and implement exponential backoff on transient network errors. If you need managed connectivity options, review MCP.

End-to-end: go live in minutes

Steps

1. Register: start your 7-day trial at Register.
2. Copy the Bearer key from your dashboard.
3. GET /api/ip with an IP address.
4. Read security.is_proxy to make your decision.

Plan and trial

The Basic plan is $29.99/mo and includes a 7-day trial or 50 requests to test your integration. Start with the trial and wire the flags into your auth, risk, or content layers before you scale out.

Operational tips that save time

• Normalize your decision function to a small, testable unit that takes { is_proxy, is_vpn, is_cloud_provider } and returns a policy outcome. This keeps your integration maintainable as rules evolve.
• Log both the input IP and the three security booleans for future audits and to tune your thresholds.
• Avoid long-term caching of negative results (e.g., is_proxy=false). These can flip.
• If you run serverless or behind a proxy/CDN, ensure you’re sending the real client IP to your backend before calling the API.

FAQ

Does proxy detection require a separate endpoint?
No. On ipXapi, proxy detection is returned on the same geolocation path: GET /api/ip with Bearer authorization.

Which field tells me if it’s a proxy?
Read security.is_proxy. You can also consult security.is_vpn and security.is_cloud_provider to refine your decision.

Can I test without committing to a paid plan?
Yes. The Basic plan is $29.99/mo and comes with a 7-day trial or 50 requests so you can validate your workflow.

Should I hardcode the sample IP from the docs?
No. The documentation uses 148.105.12.120 as an example only. Security flags are live and can change, so always test with the IPs relevant to your application.

What if the response doesn’t include the fields I expect?
Use defensive checks. If security or any of its flags are missing, default to your safest policy and log the event for later review.

Ready to check security.is_proxy from your code path? Start your 7-day trial, grab your Bearer key, and ship your integration now: Register.