IP to Company API

You need to turn an IP address into a concrete company signal you can act on—without guessing, scraping, or juggling multiple datasets. By the end of this guide you will query a single endpoint to retrieve geolocation, organization (company) attribution, network metadata (ASN), and basic security flags (proxy/VPN/cloud) that you can plug directly into routing, analytics, or fraud controls.

What the IP to Company lookup returns and how to use it

The IP to Company lookup maps an IPv4 address to organization metadata via a single request to the path /api/ip. You’ll read the org field for company attribution, and you can cross-check isp and as for network context. The same response returns geolocation (country, region, city, lat/lon), timezone, and basic security indicators including whether the IP is a known proxy, VPN, or cloud provider.

Developers typically use this for:

• IP geolocation to localize content or comply with geo-specific rules.
• Proxy and VPN detection to harden login, signup, and checkout flows.
• ASN and org enrichment to segment B2B traffic and prioritize accounts.
• Lightweight IP reputation decisions by combining org with security flags.

Account, auth, and pricing at a glance

Authentication is HTTP Authorization with a Bearer token. Include both Accept: application/json and Authorization: Bearer YOUR_KEY headers on every request.

Plans: Basic is $29.99/mo. A trial is available for 7 days or 50 requests so you can implement, test, and validate your workflow before committing. To get your key, create an account here: Register. For reference material, see the Documentation.

cURL: one request to get company, geo, ASN, and security flags

Below is the official cURL request and the corresponding JSON sample using the documented fixture IP. Keep the headers as shown. Replace YOUR_KEY with your actual bearer token when you implement.

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

Official JSON response for the documented fixture

Copying verbatim so you can see the exact field names and structure. Treat this as a product fixture; live results may differ for other IPs or over time.

{
"status": "success",
"country": "United States",
"countryCode": "US",
"region": "US-CA",
"regionName": "California",
"city": "Mountain View",
"zip": "94043",
"lat": 37.40599,
"lon": -122.0786,
"timezone": "America/Los_Angeles",
"isp": "MailChimp",
"org": "MailChimp",
"as": "AS14782 MailChimp",
"query": "148.105.12.120",
"inEU": false,
"continentCode": "NA",
"security": {
"is_proxy": false,
"is_vpn": false,
"is_cloud_provider": true
}
}

Fields you’ll actually use for IP-to-company and decisioning:

• org: Organization attributed to the IP. Use this for IP-to-company mapping.
• isp: Network service provider string; useful alongside org to understand the network context.
• as: Autonomous System information (string with ASN + name) for network-level grouping.
• country, region, city, timezone: Geolocation and local time context. Timezone is an IANA identifier.
• security.is_proxy, security.is_vpn, security.is_cloud_provider: Basic security posture flags to filter or route traffic.
• query: Echo of the IP that was looked up.

Minimal client code you can drop into your service

This example performs a single lookup against /api/ip using the same fixture IP. It illustrates the Accept and Authorization headers and parses the org, isp, as, and security flags you’ll typically read for enrichment and filtering.

# Python 3.x
import os
import json
import urllib.request

API_BASE = "https://ipxapi.com"
PATH = "/api/ip"
IP = "148.105.12.120" # fixture from docs
URL = f"{API_BASE}{PATH}?ip={IP}"

req = urllib.request.Request(URL, method="GET")
req.add_header("Accept", "application/json")
req.add_header("Authorization", "Bearer YOUR_KEY") # replace with your key

with urllib.request.urlopen(req, timeout=10) as resp:
data = json.loads(resp.read().decode("utf-8"))

# Read the fields you need
status = data.get("status")
org = data.get("org")
isp = data.get("isp")
asn = data.get("as")
security = data.get("security") or {}
is_proxy = security.get("is_proxy")
is_vpn = security.get("is_vpn")
is_cloud = security.get("is_cloud_provider")
country = data.get("country")
timezone = data.get("timezone")

print("status:", status)
print("org:", org)
print("isp:", isp)
print("as:", asn)
print("security:", {"proxy": is_proxy, "vpn": is_vpn, "cloud_provider": is_cloud})
print("country:", country)
print("timezone:", timezone)

How to extract company and classify traffic

For attribution, prefer org as the primary company field. It often reflects the business entity associated with the IP block. Compare org to isp for cases where consumer broadband or hosting providers may appear; this helps you separate B2B traffic from general consumer or cloud traffic. You can also check as for grouping by autonomous system, which is stable for many operational use cases.

To exclude non-corporate sources, combine org with security.is_cloud_provider, security.is_proxy, and security.is_vpn. For instance, if is_cloud_provider is true, you can route the session to flows optimized for headless browsers, ephemeral nodes, or QA traffic. If is_proxy or is_vpn is true, consider step-up authentication or limited functionality until the session is verified.

Operational guidance: reliability, caching, and time zones

• Availability: Treat lookups as latency-sensitive. Keep your median response time low by making requests server-side and reusing HTTP connections.
• Caching: Cache by IP for a short TTL to reduce round trips and cost. A per-IP TTL of minutes to a few hours is common depending on your risk tolerance and how frequently you observe IP mobility.
• Timeouts and retries: Use a conservative request timeout (e.g., 2–10 seconds) and implement a single retry with jitter. Log failures and degrade gracefully with a cached or default decision.
• Timezone handling: timezone is an IANA string (e.g., America/Los_Angeles). Convert server-side timestamps using this identifier if you display local times to users or teams.
• Consistency: Live flags and fields like security indicators can change over time. Do not hardcode expectations based on the fixture.
• Data minimization: Store only the fields you need (e.g., org and security flags) to limit PII exposure and simplify compliance reviews.

Mapping IP geolocation, proxy/VPN detection, ASN, and company in one pass

The /api/ip path returns the essentials most teams need for common enrichment tasks:

• IP geolocation: country, region, city, lat, lon, and timezone for routing or content decisions.
• Proxy/VPN detection: security.is_proxy and security.is_vpn for session risk gating.
• ASN context: as string for network grouping and traffic shaping.
• IP-to-company: org for company-level attribution in analytics, CRM matching, or B2B personalization.

You can run this lookup inline during request processing, or asynchronously in a background job that enriches session logs and events. For synchronous paths, apply caching and parallelize it with other service calls to keep response times predictable.

Environment and deployment notes

• Server-to-server only: Call the API from your servers. Do not expose your bearer token in browsers or mobile apps.
• Observability: Log request outcomes keyed by IP and correlate with application events to monitor uplift or false positives in proxy/VPN filters.
• Configuration: Externalize your API key in environment variables or a secrets manager. Rotate keys periodically.
• Testing: Use the documented fixture IP 148.105.12.120 in non-production tests. Do not treat the fixture as a live user’s IP.

MCP endpoint for controlled environments

If you operate in a network where outbound traffic must traverse an allowlisted egress or a managed control plane, coordinate access through MCP. You can review availability details here: MCP. Keep your request format identical: same path (/api/ip), same headers, and the same bearer token structure.

Security and abuse controls using the security flags

Basic risk screening can be built by combining org, isp, as, and security flags. As a starting point, consider:

• Block or step-up if security.is_proxy is true on sensitive endpoints (password reset, payout changes).
• Challenge sessions from security.is_vpn true when account-level risk is already elevated.
• Divert is_cloud_provider true to flows tolerant of automation (e.g., read-only endpoints), or require additional verification.

Because security flags can evolve, log decisions and maintain an appeal or review path for legitimate users who traverse a corporate VPN or mobile anomaly.

Data modeling tips for IP-to-company analytics

• Normalization: Store org as a normalized dimension for grouping traffic and accounts. Preserve the original string for auditability.
• Attribution rules: Prefer org over isp for B2B segmentation. Use as to aggregate by network ownership when org strings vary by allocation.
• Join strategy: Enrich raw logs with org, isp, as, and country at ingestion time. This avoids re-querying during analytics windows.
• Fallbacks: When any field is missing, keep your pipeline resilient by substituting a sentinel value like “unknown” rather than failing the record.

Error handling, idempotency, and edge behaviors

Keep your integration robust by isolating lookup failures from core transaction paths. If the lookup times out or returns a non-success status, fall back to cached attributes or bypass enrichment for that event. This ensures a single dependency does not block sessions.

Likewise, when rolling out new controls (e.g., proxy gating), start in logging mode, evaluate impact, then gradually enforce. This reduces user friction from unexpected VPN or cloud detections.

Capacity planning and request patterns

To minimize redundant calls, deduplicate by IP within a session window (e.g., one lookup per IP per N minutes). If your traffic includes many short sessions from the same egress (e.g., a corporate NAT), cache longer to reclaim budget. If you process logs in batch, perform lookups asynchronously and merge results into your warehouse.

When to trust org vs isp vs as

• org: Primary field for company attribution. Use this for B2B routing and marketing segmentation.
• isp: Helpful context; sometimes identical to org, sometimes consumer access providers. Use as a secondary signal in heuristics.
• as: Network-level grouping. Use when you need a broader, semi-stable aggregation layer across IP blocks.

Security and compliance reminders

Keep bearer tokens out of client applications. Restrict access to the API from your backend only. Limit retention for enriched fields and scope access internally to least privilege. If you operate across jurisdictions, your legal or compliance team may want to review how you apply geolocation and security flags in user-facing decisions.

Verification checklist before you ship

• Requests include Accept: application/json and Authorization: Bearer YOUR_KEY.
• Endpoint and path are correct: https://ipxapi.com/api/ip with an ip query parameter.
• Logs capture org, isp, as, country, timezone, and security flags for validation.
• Short-lived IP cache implemented with clear TTL and invalidation plan.
• Feature flags guarding new proxy/VPN rules to allow gradual rollout.

Frequently asked questions

How do I authenticate requests?

Use an Authorization header with a Bearer token. Include Accept: application/json. Example: Authorization: Bearer YOUR_KEY.

What is the correct endpoint and path?

Send GET requests to https://ipxapi.com/api/ip with the ip query parameter set to the IP you want to look up.

Which field should I use for company attribution?

Use org as the primary field for IP-to-company mapping. Optionally compare with isp and the as string for additional context.

Can I detect proxies, VPNs, and cloud providers?

Yes. Read security.is_proxy, security.is_vpn, and security.is_cloud_provider from the response. Handle these flags dynamically, as live values can change.

Is there a trial and what are the basics on pricing?

Basic is $29.99/mo. A trial is available for 7 days or 50 requests so you can implement and validate before upgrading.

Ready to implement IP-to-company enrichment with a single call? Create your account to get an API key, follow the examples above, and ship your integration today: Register. For full reference details and field descriptions, see the Documentation, and for controlled network access options, review MCP.