Reverse IP Lookup API: What to Look For Before You Integrate

A reverse IP lookup API takes an address in a request and returns structured data about it. What comes back depends on the kind of API: a hostname, the registered network holder, or a company with a classification. Choose by the field you need, then test it on your own addresses before integrating.

Three families of API

The phrase hides distinct products. Mixing them up is the most common reason an integration disappoints.

Type	Example data	Cost model	Main limit
DNS (reverse)	PTR hostname	Free, runs through any resolver	Often empty or generic
Registry (RDAP)	Holder, range, abuse contact	Free, rate-limited per registry	Shows the registered holder, not the end user
Company-level	Verdict, company name and domain, network class	Typically paid, per call or per plan	Most addresses are consumer or hosting space

RDAP, the modern replacement for WHOIS, is described in RFC 7480 for its HTTP usage and RFC 7483 for its JSON response format. It gives you machine-readable registry data for free. See reverse IP lookup with WHOIS for what the fields mean.

A concrete example of a company-level API

BusinessMCP documents one on its IP to company API page. According to that page, a single lookup is a GET request to /api/hub/v1/ip/{ip} and a bulk lookup is a POST to /api/hub/v1/ip/bulk with an ips array. The response identifies the company, ISP, cloud or VPN behind the address and carries one of three verdicts:

• company: the network belongs to that company, and company.domain is set only in this case.
• non_business: covers ISPs, mobile carriers, cloud hosts and VPNs.
• unidentified: the network could not be attributed.

The page advises treating anything other than company as unknown. Pricing is stated as $0.02 per call for single lookups and $0.02 per item for bulk, charged only when a result is found, prepaid with no subscription, and $5 free for 7 days. Bulk calls take 1 to 100 addresses. The page does not list the full set of response fields or state rate limits, so confirm those in the documentation before building around them. The same data powers a free web tool, which is a convenient way to see sample output before you write code.

What to evaluate in any API

Key takeaway: the best signal of API quality is that it can say “I don’t know”. A service that names a company for every address is guessing.

1. Does it return a verdict or class? You need to distinguish a business from a provider without parsing free text.
2. Is billing tied to results? Charging only when a result is found, as BusinessMCP describes, aligns cost with value. Per-request billing means you pay for the many consumer addresses that name nobody.
3. What are the limits? Look for bulk size, rate limits and timeouts. Our bulk lookup guide covers batching.
4. How fresh is the data? Ask how often the underlying database is rebuilt.
5. What is the error behaviour? Know what a malformed address, a private range or a timeout returns.
6. What does it log? If you send customer addresses, read the privacy terms; see the privacy guide.

Handling responses in code

Design your integration around the three outcomes, not just success. A named company is an enrichment. A non-business verdict is useful too, since it lets you filter bots and consumer traffic. An unidentified result is simply a gap. Code that throws an error on non-company results will fail most of the time, because on typical B2B traffic most addresses are not business networks. BusinessMCP’s guide to how visitor identification works cites roughly 20 to 35 percent company-level resolution as a vendor figure, so expect the majority of calls to return something other than a company.

Also deduplicate before you call. Logs repeat addresses constantly, and each repeat costs money on a paid plan and time on any plan. Cache results for a sensible period, remembering that holders change, and store the verdict with a timestamp so you can re-check later.

A short pseudo-flow looks like this:

1. Normalise and validate the address; skip private ranges.
2. Check your cache.
3. Call the API, with a timeout.
4. Store verdict, company, domain and the lookup time.
5. Route the outcome: enrich, filter or ignore.

See the Python example for a working version of the pattern.

Testing before committing

Export a day of real addresses, deduplicate them and run a sample through your candidate APIs. Tally verdicts, then hand-check a set of named results against company websites. Compare vendors on correct named results, not on how many addresses they filled. For a broader look at the alternatives, BusinessMCP publishes a comparison of company data APIs; it is a vendor page, so treat its framing accordingly.

Common integration mistakes

• Sending addresses from untrusted headers without validation, which lets clients influence your results.
• Treating an ISP name as a customer.
• Ignoring IPv6, which is a growing share of traffic.
• Hard-coding assumptions about response fields that the documentation does not guarantee.
• Skipping a free trial. With a trial credit, as BusinessMCP offers, there is no reason to commit before measuring.

Cost planning without surprises

Pricing models for IP APIs fall into three broad shapes: per-call billing, monthly tiers with a quota, and enterprise contracts. Each rewards a different usage pattern. Per-call billing suits irregular or experimental use, because there is no commitment. Tiers suit steady volume. Enterprise contracts suit large, predictable pipelines with support requirements.

To compare them fairly, estimate your unique addresses per day, not your raw request count. Then estimate how many of those will resolve to something billable. Under a model that charges only for found results, like the $0.02 per found lookup BusinessMCP lists on its IP API page, the effective cost per unique address is the price multiplied by your hit rate. Under a per-request model, it is the full price on every address. The same traffic can therefore cost very different amounts, and a vendor’s headline price tells you little until you apply it to your own mix.

Finally, cap spending in code. Add a daily budget guard so a bug or a traffic spike cannot run up a bill, and log how many calls return each verdict so you can see waste early.