One spec. Three systems. One of them always wrong.
Raj Patel spent several years on platform engineering teams in San Francisco where every API launch touched at least three systems: the gateway config, the internal Confluence docs, and the partner-facing reference page. They'd start identical. Within two weeks of the first change, one of them was wrong. Partners would read the reference page, hit a rate limit that wasn't documented there, and open a support ticket — which was really just a request to re-read the gateway config.
"The spec was always the source of truth," Raj says. "But it lived in a repo while the gateway lived in a config management system and the docs lived somewhere else entirely. The problem wasn't that teams didn't care about accuracy — they did. The problem was structural: three systems that needed to stay in sync had no shared source to sync from."
Endpointwise was founded in 2025, in San Francisco, to answer a single question: what if pushing your OpenAPI spec was the only step required to have a configured gateway, a hosted reference page, and a set of issuable API keys? Not three tools coordinated by hand. One push, one source of truth.
The team is three people. The product does one workflow. We're not building for teams who need a hundred features they'll never configure — we're building for platform engineers who are done reconciling systems that should never have been separate.
Team
Three people, one focus.
Raj Patel
CEO & Co-Founder
Platform engineering background. Previously built API gateway infrastructure at two growing SaaS companies. Founded Endpointwise in 2025 after one too many partner escalations caused by gateway config and reference docs being out of sync.
Sofia Andrade
Lead Engineer
Backend systems engineer with experience building API proxies and token-bucket rate limiters. Wrote the gateway core and the spec ingestion pipeline. Focused on keeping p99 latency under 10ms at the proxy layer.
Marcus Chen
Developer Experience
Spent years writing and maintaining docs for API platforms before deciding the tooling problem was more interesting than the writing problem. Built the OpenAPI-to-reference pipeline, the try-it console, and the docs search index.
Values
What we believe about API infrastructure.
Specs are contracts
Your OpenAPI spec is the authoritative description of your API. Everything else — the gateway config, the docs, the key scopes — should be derived from it automatically, not maintained in parallel.
Docs ship with the code
Documentation that requires a separate update step will always lag behind the implementation. We build tooling that makes keeping docs current the path of least resistance, not an afterthought.
Infrastructure should be invisible
A well-configured API gateway shouldn't generate support tickets. Your partners shouldn't think about the proxy layer — they should think about your API. When rate limits are documented where they're enforced and keys are scoped to the operations they need, the infrastructure stops being visible.