IP-to-Company API: How to Evaluate One Before You Buy

An IP-to-company API answers one question about an address: is this network a company’s own, and if so, whose? The mechanics — registry records, routing data, reverse DNS, and why most traffic can never be named — are covered in how visitor identification works. This guide is the buyer’s side: how to tell a good answer from a plausible one before you wire an API into your product.

The core distinction is between a raw registry name and a verdict. Every public IP is registered to someone, so any API can return a name for almost any address. A verdict says whether that name is the visitor. An API that returns only names is handing you the hard part.

curl https://businessmcp.com/api/hub/v1/ip/17.253.144.10 \
  -H "Authorization: Bearer $BUSINESSMCP_API_KEY"

{
  "ip": "17.253.144.10",
  "verdict": "company",
  "network_class": "business",
  "company": {
    "name": "Apple Inc.",
    "domain": "apple.com"
  },
  "name_hint": null,
  "confidence": 0.95,
  "country": "US",
  "asn": 714,
  "network": "17.0.0.0/8",
  "sources": [
    "bgp",
    "arin",
    "swip"
  ],
  "flags": {
    "hosting": false,
    "isp_or_mobile": false,
    "cdn_edge": false,
    "secure_egress": false,
    "sase_dedicated": false
  },
  "graph_version": "v20260926"
}

Registries record who holds an address block. That is the right answer about the block and frequently the wrong answer about the person using it. Five classes of network account for most of the gap:

SASE is the subtle one. When a company routes staff traffic through a secure-access service (Zscaler, Netskope, Cato Networks or Palo Alto Prisma Access are common examples), the visitor’s IP belongs to the vendor. A registry lookup names the vendor — and an API that passes that through will tell you a security company visited, when it was one of that vendor’s thousands of customers. Our graph flags these ranges (flags.secure_egress, flags.sase_dedicated) and declines to name anyone. It does not mark them as hosting: the visitor is a real person behind a corporate gateway, and should still count as human traffic.

Most APIs return a confidence score. A score is only useful if you know what it is calibrated against, so ask every vendor three things:

1. 1What evidence moves it? A block registered to a company, corroborated by its own mail servers or DNS, is strong. A name scraped from a free-text registry description is weak.
2. 2Where is the cut-off? Below some threshold the vendor should stop naming a company. If every score is high, the score is decoration.
3. 3Does it ever go down for carriers? A telecom operator that registers its consumer ranges under its own brand looks like a company to a naive scorer. The score should know the difference.

We expose the pieces rather than a single opaque number: confidence, the network_class (business, isp, mobile, hosting, vpn, tor, education, government), the sources that support the row, the matched network, and the nightly graph_version. Below our claim threshold a name only ever comes back as name_hint under low_confidence. The rule for consumers is simple: trust company.domain only when the verdict is company.

A vendor’s demo is run on traffic that makes the vendor look good. Your match rate is a property of your traffic mix, so the only benchmark that predicts production is one run on your own addresses.

# 1. Pull a day of real client IPs (the verified client address, never a CDN edge).
# 2. Resolve them 100 at a time and tally the verdicts.
jq -Rn '[inputs] | {ips: .[:100]}' < sample-ips.txt > batch.json

curl -s -X POST https://businessmcp.com/api/hub/v1/ip/bulk \
  -H "Authorization: Bearer $BUSINESSMCP_API_KEY" \
  -H "Content-Type: application/json" \
  -d @batch.json > results.json

jq -r '.data.results[] | .verdict' results.json | sort | uniq -c
jq -r '.data.results[] | select(.verdict=="company") | [.ip, .company.domain, .network_class, .confidence] | @tsv' results.json

Three numbers matter. Precision on named results: of the companies it named, how many are plausible visitors? Carrier and vendor leakage: how many named results are an ISP, a mobile operator, a cloud or a security vendor dressed up as a prospect? Coverage of what should resolve: of the visits you can independently tie to a company on its own network — a known customer’s office, a signed-in user whose company owns its IP space — how many did it name?

An honest range for company-level identification on B2B traffic is roughly 20–35%, and it falls on SMB and consumer-heavy audiences. We do not publish a match rate for our own API for the same reason: it depends on whose traffic you send.

Our ip_lookup costs 1 credit per address and ip_bulk_lookup resolves up to 100 per call at 1 credit each — charged whether or not a company is named, because “this is a mobile carrier” is an answer too, and one you would otherwise pay someone to work out. The first 1,000 credits a month are free, which is enough for the benchmark above. The graph is rebuilt nightly from public registry, routing and DNS data, so a range that changed hands today can be a day behind; graph_version tells you which build answered.

An IP address can be personal data under the GDPR. Naming the organisation that operates a network is business information, but what you do with it — storing it against a profile, combining it with other identifiers — is your processing. Keep raw IPs only as long as you need them, and try the free reverse IP lookup or the IP intelligence API on a sample before building on either.