Bulk IP to Company Lookup: Resolve Log Files Without Waste

A bulk IP to company lookup resolves many addresses in one job: export unique client IPs from your logs, send them in batches (BusinessMCP’s endpoint takes up to 100 per call), keep the company verdicts, treat everything else as unknown, and cache results briefly. Deduplicating first is the biggest saving.

When bulk beats single lookups

Single calls are fine for a form submission or a live alert. Bulk calls fit offline work:

• Weekly analysis of which organisations read your documentation.
• Backfilling historical logs to see trends.
• Cleaning a CRM list of sign-up IPs.
• Benchmarking vendors on one sample, as in how to test an IP to company API.

Fewer round trips mean faster jobs and simpler retry logic, and per-address pricing usually stays the same either way.

The pipeline in six steps

1. Extract. Pull the client IP column from logs or analytics. Behind a CDN or load balancer, use the forwarded client address, and only trust it for requests that verifiably passed through your proxy.
2. Normalise. Trim whitespace, lowercase IPv6, drop private ranges (10.x, 172.16-31.x, 192.168.x), loopback and malformed entries. Private addresses cannot resolve to a company.
3. Deduplicate. Keep one row per unique address per period, with a visit count.
4. Batch. Split into chunks of the vendor’s maximum size.
5. Resolve. Send each chunk, record the full response, and respect rate limits.
6. Join and filter. Join results back to the visit table. Keep company verdicts for account reporting. Keep the rest for traffic-quality analysis.

What BusinessMCP’s bulk endpoint expects

According to the IP to company API page, the bulk route is POST /api/hub/v1/ip/bulk with an ips array of 1 to 100 strings, authenticated with a bearer API key. It costs $0.02 per item, charged only when a result is found, and returns the same fields as a single lookup for each address. Full field lists are in the API documentation. Treat these details as of this writing and confirm before building.

Our Python example shows chunking and basic error handling.

Handling the answer

Verdict	Action in a batch job
company	Store name, domain, confidence, date resolved
non_business	Store the class (ISP, mobile, hosting, VPN) for traffic analysis
unidentified	Store as unknown; retry only after the data refreshes
Error or timeout	Retry the chunk with backoff; do not lose the batch

Key takeaway: keep every verdict, not just the companies. The non-company rows are the evidence for how much of your traffic is infrastructure, and they let you rerun reports without paying twice.

Cost control

• Deduplicate first. A log of a million requests may hold tens of thousands of unique addresses.
• Remove known infrastructure before the call. Crawlers and cloud ranges you already recognise do not need a lookup; see filtering bot and cloud traffic.
• Cache. Store answers with a date and reuse them for a few days.
• Sample first. Run 500 addresses, check precision and billing, then scale up.
• Estimate before running. Use the worksheet in IP to company API pricing.

Billing wording differs between vendors, and even between pages of the same vendor. Do a small batch with trial credit, compare your balance before and after, and extrapolate from what you see.

Error handling that saves reruns

• Validate addresses locally to avoid paying for malformed input.
• Write results to disk per chunk, so a crash at batch 400 does not lose batches 1 to 399.
• Log the chunk index, status code and response time.
• Retry transient failures with exponential backoff and a cap; never loop forever.
• Keep a dead-letter file of chunks that fail repeatedly.

Quality checks on the output

Before sharing results, run three quick tests:

1. Count verdicts. If nearly everything is company, something is wrong.
2. Scan the top 20 named companies by visits. If broadband or cloud providers appear, the filter step failed.
3. Hand-check about 50 named results against known customers or form fills.

If precision is low, revisit the source of the IPs; a proxy address in the log will resolve consistently to the wrong organisation.

Privacy housekeeping

A bulk job concentrates personal data in a file. Store it securely, delete the raw address column when the job is done if you no longer need it, and keep the output at company level. The GDPR article covers retention in more detail.

Reporting once resolved

A useful weekly report lists new named companies, repeat visitors, pages read and fit with your target profile. Pair it with scoring from lead scoring with IP data. If you want to test the approach cheaply, the BusinessMCP IP lookup trial credit is enough to resolve a few hundred unique addresses.

A sample schema for the results table

Whatever tool you use, store results in a shape that survives vendor changes.

Column	Purpose
ip	The address that was resolved
resolved_on	Date of the lookup, for expiry
verdict	company, non_business or unidentified
network_class	ISP, mobile, hosting, VPN, business and so on
company_name	Present only for company verdicts
company_domain	Join key to your CRM
confidence	If the vendor provides it
source	Vendor name and version or graph identifier
visits	Count from your own logs

Keeping source means you can rerun the same list on another vendor and compare, using the method in how to test an IP to company API. Keeping resolved_on makes cache expiry a simple query rather than a guess.

Scheduling and growth

Start with a manual weekly run. Once the output is trusted, schedule it daily on the previous day’s unique addresses, skip anything resolved within your cache window, and alert only on new company verdicts. As volume grows, watch three numbers: addresses per run, cost per run and share of company verdicts. A sudden change in any of them usually means a change in your traffic or a logging problem, not a change in the world.