A developer portal that can't drift from your API.
This replaces the hosted API 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.
What it replaces
A hosted docs tool publishes what someone typed. Here the reference is generated from the spec and the SDK source, so the only thing a person writes is the guides.
A hosted docs tool | Giant Context | |
|---|---|---|
The API reference | Written by hand from the spec, and edited by hand when the spec changes. | Generated from your OpenAPI spec and re-synced on a schedule, with sync status and an event log when a run fails. |
Code samples | Pasted in, and drifting from the SDK by the second release. | Extracted from your TypeScript and Python SDK repos, matched to each endpoint, with the source file and line they came from. |
Guides | Whoever on the team has time this quarter. | The AI drafts them in the same voice as your marketing site. You approve each one. |
Where it lives | A docs subdomain with its own header, its own brand and its own login. | Your domain, with the same header and footer as your site and Knowledge Base. Pricing is one click away and still your site. |
Developer questions | A support inbox. | The chat agent answers from the reference and the guides. |
Try-it-live playground | ||
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.
- You point
At your spec and repos
Give it an OpenAPI spec URL and your TypeScript and Python SDK repos in settings.
- It parses
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.
- It matches
Snippets to endpoints
SDK methods are matched to endpoints by HTTP method and path, and cURL examples are generated from the endpoint definitions.
- It stays current
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.
Real snippets, pulled from your repos
Every endpoint page shows a cURL example and the matched SDK snippets side by side. These two are illustrative. On your portal the code is extracted from your 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.
Where the edges are
If one of these is a dealbreaker, better to know now.
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.