IP Organization API

You need to determine the owning organization behind an IP address so you can make routing, abuse, or product-eligibility decisions in your app. By the end of this guide you will be able to query ipXapi’s IP Organization lookup, authenticate with a bearer token, parse the org field reliably, and ship a small integration that’s production-safe.

What the IP Organization lookup does (and when to use it)

The IP Organization lookup resolves a given IP to the organization that owns or operates the network block. In ipXapi’s response, this value is exposed as the org field. Typical uses include:

• Allow/deny or tiered handling by known orgs (for example, mail providers, cloud platforms, or corporate networks).
• Attribution in logs and analytics where knowing the responsible organization clarifies traffic patterns.
• Operational routing, such as sending certain providers through different flows.

This guide focuses on the org field and the single lookup path /api/ip with a documented fixture IP to keep examples deterministic.

Access, authentication, and control plane

Requests are authenticated with an HTTP Authorization header using the Bearer scheme. Use your live token in the format Authorization: Bearer YOUR_API_KEY. You can create an account and get a key via the registration flow.

• Sign up: the Basic plan is $29.99/mo; the trial is 7 days or 50 requests.
• Management Control Plane (MCP): browse the control plane at MCP for account and key management.
• Reference materials: see Documentation for the latest endpoint notes.

Make a lookup request (copy-paste)

The IP Organization lookup uses the path /api/ip. The official fixture below targets 148.105.12.120 and is safe to test with. Keep in mind that live flags may differ in real-time calls; do not treat the fixture as your user’s IP.

Official cURL:

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

Official JSON (product fixture):

{
"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 will actually use for the organization lookup:

• org: the owning or operating organization for the queried IP.
• query: echoes the input IP, useful for logging and correlation.

Other fields can help you make contextual decisions (for example, timezone or security flags), but this guide stays centered on org.

Parse the org field in code

The example below requests the same endpoint and extracts org from the JSON. It uses the documented fixture IP 148.105.12.120 and the Authorization: Bearer scheme. Replace YOUR_API_KEY with your token when you run it.

#!/usr/bin/env python3
import json
import sys
import time
import urllib.request

API_URL = "https://ipxapi.com/api/ip?ip=148.105.12.120"
REQ = urllib.request.Request(
API_URL,
headers={
"Accept": "application/json",
"Authorization": "Bearer YOUR_API_KEY",
"User-Agent": "ip-organization-guide/1.0"
},
method="GET"
)

def fetch_org():
try:
with urllib.request.urlopen(REQ, timeout=10) as resp:
if resp.status != 200:
raise RuntimeError(f"HTTP {resp.status}")
payload = json.load(resp)
except Exception as e:
raise SystemExit(f"Request failed: {e}")

# Minimal validation: ensure status looks OK and org is present.
status = payload.get("status")
org = payload.get("org")
ip_echo = payload.get("query")

if status != "success":
raise SystemExit(f"Lookup returned non-success status: {status!r}")
if not org:
raise SystemExit("Response did not include 'org'")

# Output for your application. In production, you may return this from a function.
print(f"IP: {ip_echo} belongs to organization: {org}")

if __name__ == "__main__":
fetch_org()

Notes:

• The code treats org as required for your use case; if absent, it fails fast so you can decide a fallback policy.
• A 10-second timeout avoids hanging processes. Tune for your environment.
• Use a meaningful User-Agent to help with support and debugging.

Implementation details that save time

Productionizing an IP Organization lookup involves a few small choices that prevent noisy failures and keep latency down. The points below are specific to the /api/ip path and org-driven use cases.

• HTTP semantics: Use GET on /api/ip with a single ip query parameter. Set Accept: application/json and include Authorization: Bearer YOUR_API_KEY.
• Caching: Organization data for a given IP is relatively stable compared to session-level attributes. Cache org per IP in-memory for minutes to hours depending on your tolerance for drift. Use an external cache (for example, Redis) if you share results across services.
• Freshness: While org is stable, network allocations can change. Establish a background refresh job that re-validates frequently queried IPs on a rolling basis.
• Timeouts and retries: Prefer a short request timeout (for example, 5–10 seconds). If you implement retries, keep them bounded with exponential backoff and a global cap to avoid thundering herds.
• Fallback logic: Decide what to do when org is missing or a transient network error occurs. Options include default-routing, flagging the session for review, or skipping org-based rules for that request.
• Logging: Log the query field from the response to confirm you evaluated the intended IP, and include your request ID for traceability.
• Rate and usage: If you are in a trial (7 days or 50 requests), consider enabling caching early so dev/test environments remain within trial limits. For plan details and updates, consult the Documentation.

Quality checks for the org value

Once you parse org, you may want to standardize and validate it before applying business logic. Here are practical checks:

• Normalization: Compare using a case-insensitive match. Some org strings may include legal suffixes; store a canonical form if you maintain allow/deny lists.
• Auditability: Persist the exact org string alongside the decision you made so you can reconstruct historical outcomes even if future lookups differ.
• Change detection: If a previously seen IP suddenly maps to a different org, trigger a low-priority alert to update your rules.
• Testing: Build a unit test that asserts org equals the expected string for the fixture IP 148.105.12.120 so regressions in your parsing pipeline are caught early.

Operational workflows and environments

How you run the lookup in different environments affects stability and cost. Keep these steps in mind:

• Local development: Use the documented fixture IP 148.105.12.120. Rate-limit your local CLI or test suite; memoize responses to avoid repeated calls.
• CI pipelines: Stub your HTTP client by recording the official JSON. Alternatively, run integration tests against /api/ip with a dedicated test key and quotas configured in the control plane.
• Staging versus production: In staging, disable long-lived caches so you can see real responses during validation. In production, enable caching and circuit breakers around the remote call.
• Monitoring: Track success rate, median/95th percentile latency, and count of fallbacks. Include the status field and a count of org-missing events.
• Data handling: If you store IPs or org values, ensure retention and access patterns align with your privacy and compliance requirements.

Troubleshooting checklist

• 401/403 errors: Ensure the Authorization header is in the form Authorization: Bearer YOUR_API_KEY and that your key is active in the control plane.
• Unexpected payloads: Confirm Accept: application/json is present. Log the raw body when parsing fails to inspect the exact structure.
• Networking: If calls hang, shorten timeouts and verify DNS, proxies, or egress firewalls between your runtime and ipxapi.com.
• Fixture drift: Live flags may change. Validate only the org and query fields if your test depends on fixed values; do not assert transient fields.
• Input validation: Sanity-check the ip parameter before sending the request to avoid avoidable errors from malformed input.

FAQ

What endpoint and method do I use for the organization lookup?
Use GET on /api/ip with the ip query parameter. Example: https://ipxapi.com/api/ip?ip=148.105.12.120

Which response field contains the owning organization?
The org field holds the owning or operating organization for the queried IP.

How do I authenticate?
Send Authorization: Bearer YOUR_API_KEY and Accept: application/json on each request.

Can I cache results?
Yes. Organization values change infrequently; cache by IP for your preferred TTL, then refresh in the background.

How can I manage my key and plan?
Use the MCP to manage keys and review usage; see the Documentation for additional details.

Ready to integrate the IP Organization lookup into your workflow? Start your 7-day or 50-request trial and get your bearer token here: Register.