A developer portal that can't drift from your API.
This replaces the ReadMe or GitBook docs that go stale weeks after launch. Point it at your OpenAPI spec and your SDK repos. It parses the endpoints, extracts real code snippets, and publishes a reference site under your domain, with the same header and footer as your marketing site. The reference is downstream of your source, so it stays current.
Docs downstream of the source of truth
Guides are the only content a human writes. The reference pages are generated, so they cannot fall out of step with the real API.
At your spec and repos
Give it an OpenAPI spec URL and your TypeScript and Python SDK repos in settings.
Endpoints, schemas, and methods
It indexes every endpoint into API groups by tag, extracts parameters and response schemas, and pulls methods and signatures from your SDK source.
Snippets to endpoints
SDK methods are matched to endpoints by HTTP method and path, and cURL examples are generated from the endpoint definitions.
Re-synced from source
The API reference re-syncs from your spec on a schedule, and the SDK snippets from your repos, so a new endpoint or method appears without anyone editing docs.
Two kinds of sync
OpenAPI sync
Endpoints organised into groups by tag, with parameters, request bodies, and response schemas extracted and displayed. Trigger a sync by hand, or let it run on a schedule; sync status and a full event log with error details are there when something fails.
SDK sync
Configure GitHub repos for your TypeScript (npm) and Python (PyPI) SDKs. The system clones the repo, parses the source, and stores code snippets per language with source file and line references, tracking the commit SHA to skip redundant syncs.
Real snippets, pulled from your repos
Every endpoint page shows a cURL example and matched SDK snippets side by side. These are illustrative; on your portal the code is extracted from your actual source, with the file and line it came from.
cURL
curl https://api.yourcompany.com/v1/contacts \ -H "Authorization: Bearer $YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "email": "ada@example.com", "name": "Ada Lovelace" }'client.ts
import { YourApi } from "@yourcompany/sdk";
const api = new YourApi({ apiKey: process.env.YOUR_API_KEY });
const contact = await api.contacts.create({ email: "ada@example.com", name: "Ada Lovelace",});The auth your API supports, shown to developers
Configure which methods your API accepts, and they appear in the reference so developers know exactly how to authenticate.
API Key
The simplest path, shown right in the reference.
HTTP
Bearer or Basic authentication.
OAuth 2.0
For portals that need delegated access.
OpenID Connect
Identity on top of OAuth, documented for developers.
One platform, one brand, one domain
Most developer-facing companies keep docs on ReadMe, the marketing site on Webflow, and the blog on WordPress, and nobody maintains any of them. Here the portal shares one brand, one domain, and the same header and footer as your marketing site and Knowledge Base. A developer who lands on your API reference and clicks Pricing does not leave your site for a different tool.
The same AI that writes your marketing copy writes your developer guides, in the same voice, grounded in the same business context. For a team already on Giant Context, adding a portal is a settings page, not a procurement decision. And the chat agent can answer developer questions using your reference and guides as grounding.
Where the edges are
Point it at your spec and read the reference
Ask for early access. Give the portal an OpenAPI spec and an SDK repo, run a sync, and browse a reference site that reflects your real API — under your own domain.