Building ProWebLook's edge IP API.

I recently shipped an edge-first IP lookup API for ProWebLook, exposed at ipapi.proweblook.com. The goal was simple: make IP intelligence feel instant while keeping the existing billing, API-key, and user-account model intact.

focus edge IP intelligence

Low-latency IP lookups served near the requester instead of forcing every call through the origin app.

stack Cloudflare + PHP origin

Workers and KV at the edge, with the existing CodeIgniter/MySQL application kept as the source of truth.

principle fast path, private core

Public endpoint for lookups; signed internal sync for usage. No raw API keys in the edge store.

The problem

ProWebLook already had IP tooling, but an IP API is only useful if it is fast enough to sit inside other workflows: fraud checks, enrichment, request routing, logging, analytics, and security filters. A normal origin-first API works, but every lookup pays for distance, app boot time, database pressure, and quota bookkeeping on the critical path.

For this version I wanted the lookup path to be edge-first. The origin application still owns accounts, billing, admin flows, and user state, but the request that asks "what is this IP?" should be answered as close to the caller as possible.

The public-safe architecture

The API runs behind ipapi.proweblook.com. A Cloudflare Worker handles the public request, validates the API key by hash, serves data from edge-friendly storage, and records usage without waiting for the origin database to finish the update.

Worker at the edge: handles request validation, response shaping, and fast-path lookup behavior.
KV-backed key state: stores API-key hashes and quota metadata needed by the edge, not plaintext keys.
Origin as source of truth: the existing ProWebLook app still owns users, admin key rotation, and balances.
Signed usage sync: edge usage is reconciled back to the origin through a server-to-server HMAC-protected endpoint.
Async quota updates: lookups are not blocked on MySQL writes, so latency-sensitive work stays on the fast path.

What changed in production

The important part was not only deploying a Worker. The product already had users and API keys, so the migration needed a bridge between the existing account system and the new edge layer.

Existing keys were backfilled into Cloudflare KV as hashed records, new key rotation now syncs to the edge store, and lookup usage flows back to the origin asynchronously. I also kept private configuration out of git by using local, ignored config files for secrets and deployment-specific values.

What I am not publishing

This is a public report, not a source dump. I am intentionally leaving out API tokens, exact internal endpoint names beyond the public surface, database details, business rules, and anything that would make abuse or reverse engineering easier.

The interesting technical lesson is the shape: put low-latency read work at the edge, keep account truth at the origin, sync the minimum state required for authorization, and use signed internal calls for reconciliation.

Next benchmark work

I built this for millisecond-class responses, but I do not want to publish loud speed claims without numbers. The next public version should include benchmark data: p50, p95, cold-start behavior, regional samples, and comparison against the old origin-first path.

Until then, the honest claim is this: ProWebLook now has an edge-first IP API foundation designed for speed, safer key handling, and asynchronous quota sync.