OpenLookup

Why It Exists

OpenLookup began as an internal utility we rebuilt for the fourth time. Every product we ship needs the same primitives: is this email real? Is this phone number reachable? Is this signup a bot? Each time, we hand-rolled a slightly different, slightly worse version.

The turning point was simple: if we keep rebuilding it, other people do too. Make it an API.

The Problem

Verification tooling is dominated by enterprise sales processes, opaque pricing, and SDKs that feel like they were shipped in 2013. Developers — the actual users — get stuck integrating tools they don't enjoy.

The Build

We're building OpenLookup the way we'd want to consume it:

• REST-first, predictable JSON, one consistent error format
• Honest latency — every response includes what was checked and what was skipped, because silent partial results are how trust dies
• Flat, public pricing — no "contact sales" for a validation API

The engineering focus is the boring, hard part: provider failover, caching layers that respect data freshness, and idempotency.

What We Learned

So far: building infrastructure is a different sport than building products. The feedback loop is longer, the stakes are correctness, and the documentation is the product.

Current State

In active development, private testing phase. Public launch ahead.