IP ISP API

You need to identify a user’s Internet Service Provider (ISP) from an IP address and wire that result into your app without guessing at undocumented fields or endpoints. By the end of this guide you will query ipXapi’s IP ISP lookup, extract the isp field reliably, handle auth, and ship a minimal, production-ready integration.

What this guide covers

This post is a developer-focused walkthrough for the ipXapi IP ISP lookup. It uses the documented path, a known fixture IP, and exact sample output so you can copy and run requests quickly. You will learn how to authenticate with a Bearer token, request the IP record, and consume the isp value from the JSON response. You will also see practical notes on timeouts, caching, and handling changing live flags.

Everything here stays on the single IP lookup endpoint and the isp field. No alternate endpoints or invented fields are introduced. When you are ready to explore beyond this single field, consult the official Documentation.

Endpoint and authentication

The IP ISP lookup is read via a single HTTP GET request:

• Path: /api/ip
• Method: GET
• Base host: https://ipxapi.com
• Query parameter: ip (an IPv4 address)
• Auth: Bearer token in the Authorization header
• Accept: application/json

For management and control-plane tasks, ipXapi’s MCP is available at MCP. Your application runtime calls go to the main host above.

In this guide, requests target the documented fixture IP 148.105.12.120 to ensure your first call matches the official sample. In production you will pass the user’s IP (or another IP you need to inspect) to the same endpoint. Do not treat the fixture as your end user’s IP.

Quick start with curl

Use the official curl below to confirm your credentials and observe the isp field in a successful response. Copy it as-is and replace the bearer token with your own only when you run it locally.

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

Official response sample

Below is the official, product-fixture JSON for IP 148.105.12.120. Live data flags can change in production queries, but for the fixture you should see this payload. Your integration should be written against the keys exactly as shown, and for the ISP lookup specifically you will read the isp field.

{
"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 typically read for an ISP lookup:

• isp: The Internet Service Provider string (what you are integrating around).
• query: The IP address that was looked up; useful for logging and correlation.

All other fields are present in the official sample and may be useful in broader geolocation or risk workflows, but this guide focuses on the isp field. When testing with live IPs, values are subject to change over time.

Production-ready Python example

The script below calls the same endpoint and prints only the isp value. It uses a tight timeout, minimal error handling, and clear exit codes to fit into CI and server-side jobs. Replace YOUR_API_KEY with your token before running.

import sys
import json
import requests

API_HOST = "https://ipxapi.com"
ENDPOINT = "/api/ip"
IP = "148.105.12.120" # replace at runtime with a user IP when needed
TIMEOUT = 5 # seconds

def fetch_isp(ip):
url = f"{API_HOST}{ENDPOINT}"
params = {"ip": ip}
headers = {
"Accept": "application/json",
"Authorization": "Bearer YOUR_API_KEY",
}
try:
resp = requests.get(url, headers=headers, params=params, timeout=TIMEOUT)
except requests.exceptions.Timeout:
raise SystemExit("Timeout calling ipXapi")
except requests.exceptions.RequestException as e:
raise SystemExit(f"Request error: {e}")

if resp.status_code != 200:
raise SystemExit(f"HTTP {resp.status_code}: {resp.text}")

try:
data = resp.json()
except json.JSONDecodeError:
raise SystemExit("Non-JSON response from ipXapi")

# Defensive extraction: default to empty string if not found
isp = data.get("isp", "")
query = data.get("query", ip)

if not isp:
raise SystemExit(f"No 'isp' in response for IP {query}")

return isp, query

if __name__ == "__main__":
isp, query = fetch_isp(IP)
print(f"{query} isp={isp}")

Notes:

• Authorization uses a Bearer token in the header. Keep the Accept header set to application/json for explicit content negotiation.
• The code surfaces non-200 responses and non-JSON responses immediately so you can catch misconfiguration during deployment.
• When moving past the fixture, supply the IP value at runtime via environment or CLI so you can reuse the same logic for any lookup.

Request shaping, reliability, and caching

Timeouts: Set a client-side timeout so your request does not hang your web thread or job runner. The sample uses 5 seconds, which you can tune based on your environment’s latency budget.

Retries: If you implement retries, ensure they are bounded and only retry idempotent GETs on transient network errors. Avoid retry storms by adding brief jittered backoff.

Caching: The ISP for a given IP does not change frequently, but it can change. Cache positive lookups for a practical window suitable to your application’s tolerance for staleness (for example, hours to days). Invalidate cache entries whenever you receive an error for a known-hot IP and re-fetch.

Logging: Log the query value and the extracted isp. Avoid logging tokens or raw JSON in production logs. Log HTTP status codes and time-to-first-byte to observe performance.

Security flags: Some fields in the response (such as booleans under a nested object) may change over time for live IPs. If you only need isp, do not gate logic on other fields without checking the latest Documentation.

Character encoding: Responses are UTF-8 JSON. If you write the isp string to storage or headers, ensure your pipeline preserves UTF-8 to avoid truncation or encoding errors.

Timezone: A timezone string appears in the official sample. If you display or store times alongside lookup results, record the timezone string as metadata so you can interpret timestamps consistently. For this ISP-focused integration, you generally do not need to transform timezones.

Command-line and service integration patterns

Command-line usage: The curl example is sufficient for smoke tests and debugging in CI. Add -sS to silence progress while preserving errors, and pipe through jq only if your environment has it installed. Keep the Authorization header verbatim with Bearer to match the API.

Server-side usage: For backends in any language, the main steps are consistent: construct the GET to /api/ip with the ip query parameter, add Accept and Authorization headers, parse JSON, then read isp. Make sure your HTTP client is configured to reuse connections (keep-alive) to reduce latency and load.

Frontend usage: Direct-from-browser calls are generally avoided when an API requires a secret bearer token. Proxy the request through your backend, or inject only the minimal result (the isp string) into your frontend state after your server has fetched it.

Error handling and observability

Non-200 responses: Treat non-200 as failures to be retried or surfaced, depending on your context. Capture the response body for diagnostics in a secure log. Avoid automated infinite retries.

Missing fields: If isp is missing or empty, consider the lookup inconclusive. Fall back to a default UX, or defer the decision that depends on the ISP until a later attempt.

Input validation: Validate IP format before calling the API to avoid unnecessary requests. If your application accepts user-supplied IPs, sanitize input and reject malformed values early.

Rate and fairness: If you batch lookups, spread them out to avoid sudden spikes. The API’s documented behavior can evolve; consult the Documentation for any updates related to throughput guidance.

Pricing and account setup

Trial: 7 days or 50 requests. This is enough to complete development and initial staging verification.

Basic: $29.99 per month. Choose this when your integration moves to production and you need predictable access beyond the trial window.

Create your account via the Register page. After sign-up, you can manage keys and inspect usage via the MCP, and you can reference the full parameter and field list in the Documentation.

Testing strategy

Fixture verification: Always start with the known fixture IP 148.105.12.120 to confirm your request signing, headers, and JSON handling match the official sample. Keep this check in a small CI test to catch regressions.

Variable inputs: Once the fixture passes, test a handful of real IPs you control to exercise parsing and to confirm your logs and caching behave as expected. Do not assume any ISP string format beyond what the JSON provides; treat it as opaque text.

Failure injection: Simulate timeouts and non-200 responses locally to verify your retry and fallback branches. Confirm the application remains responsive and that you do not spam retries.

Deployment checklist

• Use Authorization: Bearer with your token in the header.
• Send Accept: application/json and parse JSON strictly.
• Call GET https://ipxapi.com/api/ip with the ip query parameter.
• Extract only the isp field for this integration’s decision path.
• Add a client timeout and, if needed, conservative retries with backoff.
• Implement short- to medium-lived caching per your staleness tolerance.
• Log query and isp minimally; never log secrets.
• Verify the fixture IP in CI to catch regressions early.

FAQ

Q: Which endpoint returns the ISP for an IP?
A: Use GET https://ipxapi.com/api/ip with the ip query parameter. Read the isp field from the JSON response.

Q: How do I authenticate?
A: Include an Authorization header with a Bearer token. Example: Authorization: Bearer YOUR_API_KEY. Also send Accept: application/json.

Q: Can I cache results?
A: Yes. ISP values for a given IP are relatively stable but can change. Cache responses for a time window that suits your staleness tolerance and revalidate as needed.

Q: Do response fields ever change?
A: Live flags can change over time for real IPs. Write your code defensively and read only the fields you need (isp for this integration). Refer to the Documentation for the canonical field list.

Q: Where do I manage my key and monitor usage?
A: Use the MCP to manage account resources and review activity.

Ready to add ISP awareness to your product? Create an account to get your key, run the fixture request, and ship your integration today. Start here: Register.