API gateway + developer documentation
Rate limits, auth keys, and a reference generated from your spec — so a partner integrates in an afternoon, not a sprint.
Gateway config + docs: one system or two?
Gateway config lives in Kong or AWS API Gateway. Docs live in Confluence. A partner asks "what's the rate limit for /invoices?" and nobody knows which system has the answer.
Each new endpoint requires a gateway PR, a Confluence page update, and a Slack message to the integration channel. Three steps, three tools, three people.
Partner onboarding takes a sprint. They're waiting for API keys, reading stale docs, and pinging your team to resolve conflicts between what the spec says and what the gateway actually enforces.
Rate limits are defined on the endpoint, in the same place the docs live. A partner reads the reference page and sees exactly what the gateway enforces — because they're the same record.
Push your OpenAPI spec once. The gateway routes are configured and the reference page is generated in the same operation. One push, one source of truth.
Partners get a live reference page and a scoped API key in the same afternoon. Your team doesn't get paged. Onboarding is self-serve.
API Gateway
Configure burst and sustained limits per endpoint, per key, or globally. When a partner hits a wall, the error response points them directly to the documented limit — no support ticket required.
Per-route config means your /v1/invoices endpoint can have different limits from /v1/reports. Burst allowances for real-time operations, sustained limits for batch jobs.
API Keys
Scoped keys that say what they can do. Set expiry dates, restrict to specific endpoints, and see the last-used timestamp without digging through logs.
Rotation without breakage: issue a new key, set an overlap window, watch the old key drain to zero traffic, then revoke it. One-day migrations, not one-week incidents.
Auth docsReference Documentation
Push your spec once and get a hosted reference page that stays in sync with your gateway config. Try parameters, see live request/response examples, and annotate endpoints with prose that only a human can write.
Custom domain support, versioned docs, and a try-it console that uses real API keys — because your partner should be able to test before they write a line of code.
Quickstart guideHow it works
The workflow maps to how platform engineers already think. No new concepts, just fewer systems.
One CLI command ingests your spec, configures gateway routes, and generates the reference page.
$ npx endpointwise push --spec ./openapi.yaml
✓ Spec validated (OpenAPI 3.1)
✓ 14 routes configured
Set per-endpoint limits in the dashboard or via config-as-code. Issue scoped keys with expiry dates directly from the same UI.
Share the reference URL and the API key. Your partner can read the rate limits, try the endpoints, and make their first authenticated request — all without pinging your team.
From the teams who've onboarded their first partner with Endpointwise.
We'd been managing our gateway config in one repo and our docs in Confluence for two years. The spec and the enforced rate limits were always one PR out of sync. Endpointwise collapsed that into a single push command. Our last partner integration was four hours start to finish — our previous record was eight days.
We'd had an OpenAPI 3.0 spec for every endpoint for two years. We just never had a way to turn it into a reference page a partner could actually use — with live rate limit info, a try-it console, and scoped keys. Now every integration handoff is: here's the URL, here's your key.
Eight microservices, eight different docs situations — some on Notion, one literally a README. Getting everything onto one reference portal with consistent structure and accurate per-endpoint rate limits was worth the migration time on its own. Partners stopped asking the same onboarding questions.
Self-serve. No gatekeeping.
Push your spec, issue a key, share the reference URL. No professional services required.