Building ProWebLook's edge IP API.

The problem

ProWebLook already had IP tooling, but an IP API has to be quick enough to sit inside other systems: fraud checks, request routing, enrichment, analytics, logging, and security filters. If every lookup has to travel back to the origin app, the call picks up distance, app boot time, database pressure, and quota bookkeeping before it can answer a simple question.

For this build I moved the lookup path to the edge. The PHP app still owns accounts, billing, admin flows, and user state. The request asking "what is this IP?" is handled close to the caller.

How it works

The public API runs behind ipapi.proweblook.com. A Cloudflare Worker validates the API key by hash, serves the lookup from edge storage, shapes the JSON response, and records usage without waiting for a MySQL write to finish.

• Worker at the edge: request validation, lookup, and response formatting stay on the fast path.
• KV-backed key state: the edge stores API-key hashes and quota metadata, not plaintext keys.
• Origin as source of truth: the existing ProWebLook app still owns users, admin key rotation, and balances.
• Signed usage sync: usage goes back to the origin through a server-to-server signed endpoint.
• Async quota updates: lookup latency does not depend on the origin database write.

Production work

The real work was not just deploying a Worker. The product already had users and API keys, so I had to connect the existing account system with the new edge layer without changing the way customers use the API.

Existing keys were backfilled into Cloudflare KV as hashed records. New key rotations sync to the edge store, and lookup usage is reconciled back to the origin asynchronously. The important pattern is simple: keep account truth in the app, move the read-heavy lookup path closer to the user.

Benchmarking the edge path

I did not want to publish a speed claim from one lucky curl response. The benchmark uses a fixed IP list, one runner, one timeout, warmup requests, and the same summary numbers for every provider.

I measured two ProWebLook paths separately: the normal public endpoint at /v1/ip and the no-fallback benchmark endpoint at /v1/benchmark/ip. The first is the real product path. The second isolates the edge lookup path.

• Latency: p50, p90, p95, p99, average, min, max, and per-IP breakdowns.
• Reliability: success rate, HTTP errors, provider-level errors, and timeouts.
• Payload cost: median response body size, because large responses still affect real integrations.
• Data parity: normalized country, region, city, latitude, longitude, timezone, ASN, and ISP fields.
• Run setup: warmups are excluded, provider order is shuffled, and every request uses the same timeout.

Benchmark result: #1 by p95

On July 1, 2026, I ran the benchmark from my local machine against four public IPs: 194.25.36.25, 8.8.8.8, 1.1.1.1, and 208.67.222.222. Each provider got two warmup requests per IP and five measured requests per IP. Warmups were not counted in the table.

Ranking rule: a provider had to return a successful response for every measured request. IPWHOIS.io had some fast responses, but five requests timed out, so I kept it in the table and did not rank it. ipapi.co returned HTTP 429 from this runner during a separate smoke test, so it stays in the competitor list until I can test it with usable quota.

Benchmark process

The claim is tied to this run, this provider set, and this ranking rule. I am calling ProWebLook #1 here because it had the lowest p95 among providers that completed every measured request.

• Command: npm run benchmark:ipapi -- --providers proweblook,proweblook-benchmark,iplocate,ip-api,ipwhois,ip2location,ipinfo --runs 5 --warmups 2 --pause 450
• Runner: local development machine on July 1, 2026 at 09:54 IST.
• Timeout: each request had an 8000ms ceiling.
• Samples: four IPs, five measured requests per IP, twenty measured requests per provider.
• Warmups: two warmup requests per IP were sent first and excluded from published stats.
• Order: provider order was shuffled per run to reduce ordering bias.
• Keys: API keys were loaded from environment variables and were not written into the output.
• Ranking: ranked providers needed 100% success, then the lowest p95 won.

Competitors tested

This first run uses providers I could call directly from the harness. Some commercial providers still need paid benchmark keys before they can be included in the ranked table.