API references, DeveloperHub
API references

Your spec in.
A reference developers use.

Point us at the OpenAPI file you already have. You get the expanded reference, code examples in ten languages, and a playground that fires real requests, so a developer can call the endpoint on the page that explains it.

14-day trialNo cardOpenAPI 2 to 3.2 See a live reference →

Guides and API references in one portal, under one search bar. The docs editor lives here →

reference / users / get a user Playground
GET /v1/users/usr_123 Send
AuthorizationBearer sk_live_•••••••• Acceptapplication/json expandplan
01 · Generate

Import the spec. The reference is already written.

OpenAPI 2, 3, 3.1 and 3.2, plus Swagger, in YAML or JSON. Everything arrives fully expanded, so nobody has to resolve a $ref in their head to work out what the response looks like.

oneOf, allOf and anyOf rendered readably, not dumped
Webhooks, OAuth flows and callbacks (OAS 3.1 and up)
Constraints, enums and multiple hosts carried through
Unlimited API references per version
OpenAPI 2OpenAPI 3OpenAPI 3.1 OpenAPI 3.2SwaggerYAML JSONWebhooksCallbacks OAuth 2.0
openapi.yaml reading
POST/v1/usersCreate a user
GET/v1/users/{id}Get a user
PUT/v1/users/{id}Update a user
DEL/v1/users/{id}Delete a user
GET/v1/ordersList all orders
POST/v1/webhooksRegister a webhook
✓ 12 operations4 schemas expanded2 security schemes
Code examples

Ten languages, generated, never stale.

Every operation ships with ready-to-copy examples built from your spec, with the auth header already filled in. Change the spec and every snippet changes with it, which is more than can be said for the ones pasted into your README in 2023.

cURLPythonNode.jsGoRubyJava
request and response, side by sideCopy
Any number of specs

One per service, one per version, one portal.

There is no cap on API references. Host one per microservice, keep a reference per published version, and let readers move between them without leaving your docs. Very large definitions load fine.

Payments APIv3.2 · 84 operations
Identity APIv2.0 · 31 operations
Webhooks APIv1.4 · 12 operations
See a live reference →
02 · Try it live

Reading about an endpoint is not the same as calling it.

The playground sits on the reference page itself. Headers, parameters and OAuth flows come pre-populated from your spec, the response comes back with its status and timing, and nobody has to open Postman to find out what a 422 looks like.

Pre-populated from your OpenAPI spec
OAuth 2.0 flows and Bearer auth built in
Live responses with status, headers and timing
Readers save their own key once and it fills in everywhere
See the docs editor →
POST/v1/payments
Authorization: Bearer sk_live_•••••
201 Created168ms · 1.2 kB
{ "id": "pay_8c21", "status": "succeeded" }
Personalised auth

A reader pastes their own API key once. Every playground call and every code sample on every page then uses it, so the snippet they copy is the snippet that works.

Auth flows, not auth screenshots

Authorisation code, client credentials, PKCE and plain Bearer. The playground runs the flow rather than describing it in a paragraph nobody reads.

03 · Design

One editor, three views, linting in all of them.

Most OpenAPI editors make you choose: a friendly form that hides half the spec, or raw YAML with a linter that shouts after the fact. This is the same document in Visual, Split and Source, linted live in every one.

API editor

Edit OpenAPI without memorising OpenAPI.

Fill in a form if you want one, drop into YAML when you need to, or keep both open side by side. Errors and warnings appear as you type, and clicking an issue takes you to the exact line that caused it.

Visual, Split and Source views over one document
Live linting in every view, errors and warnings as you type
Click any issue to jump straight to the line
OpenAPI 2, 3, 3.1 and 3.2, YAML or JSON
Try the free API editor →
VisualSplitSource ▲ 2 issues
▾ /users
  GET /users/{id}
  POST /users
▸ /orders
▸ /webhooks
openapi: 3.1.0
paths:
/users/{id}:
get:
summary: Get a user
operationId:
responses:
Issues
AllErrorsWarnings
Warn operation-operationId Operation must have an operationId :6
Error no-$ref-siblings $ref cannot be placed next to other properties :41
04 · Keep it fresh

The reference should update itself.

An API reference is out of date the moment someone merges. Push the spec from your pipeline, sync the repo both ways, and let the changelog explain what changed, drafted from the diff rather than from memory.

CI/CD updates

One curl in your pipeline. That is the integration.

Post the OpenAPI definition to our API on every build. Readers get the new version the moment the build goes green, with no manual upload and nobody remembering to do it on release day.

$ curl -X POST \
  https://api.developerhub.io/v1/apis/upload \
  --data-binary @openapi.yaml
  ✓ reference updated to v2.5.0, live at docs.acme.dev/api
GitHub sync

The spec lives in the repo. So do the docs.

Keep the OpenAPI file and the written pages under version control and push a commit. Sync runs both ways, on every branch, every pull request and every release, and the checks run before anything merges.

#312 feat/webhooks → main
OpenAPI spec valid
Broken links: 0 found
3 new operations documented
Reference synced · live at docs.acme.dev/api
For developers →
OpenAPI AI Agent

An agent that works on the spec itself.

Our AI agents cover the reference as well as the guides. The OpenAPI AI Agent works on the specification behind your reference, and like every agent here it drafts rather than publishes: you read the changeset before a reader sees any of it.

How our AI agents work →
API changelogs

Tell them what broke before they find out.

Native changelogs with an RSS feed, so integrators can subscribe to your breaking changes instead of discovering them in production. The agent drafts each entry from the diff between spec versions, including the deprecations you would have forgotten.

Breaking changes, new endpoints and deprecations
Drafted from your spec diff, edited by you
RSS feed, independent of your version tree
Explore changelogs →
Changelog RSS
New v2.5.028 Apr 2026
Webhooks and the /v1/events endpoint
Breaking v2.4.010 Mar 2026
Auth header renamed to Bearer
05 · Structure

One long page, or a page per endpoint.

Every OpenAPI definition loads, however large it has grown. Render it as a single scrolling reference when it is small enough to skim, or give each operation its own page when it is not.

A deep-linkable, shareable URL for every operation
Clean, SEO-friendly paths on very large references
Switch layout without touching the spec
Single page
docs.acme.dev/reference
POST
GET
PUT
DEL
GET
every operation, one scroll
Page per endpoint
Create a user
Get a user
Update a user
Delete a user
/reference/get-a-user
GET
its own URL, its own search result
06 · One portal

Guides and reference, under one search bar.

Most companies run the tutorial on one platform and the reference on another, and readers pay for it. Here they are the same portal: deep-link any operation from any guide, and search once across both.

Deep-link any API operation from any guide page
One search bar across guides, references and code steps
Unified navigation, so nobody switches context to read a schema
Guides and API references side by side in one portal
Explore the AI Assistant →
Send the token you got from POST /v1/auth/token as a Bearer header on every request. Tokens last 24 hours, then call POST /v1/auth/refresh.

Everything developers expect, already there.

Instant AI answers

Semantic search across endpoints, parameters and descriptions.

Auth personalisation

Readers add their key once; every call and snippet updates.

Webhooks and callbacks

Full OAS 3.1 and 3.2 support, rendered properly.

Search analytics

See which endpoints developers cannot find, then fix it.

Private API docs

Gate internal references behind SSO, magic links or JWT.

Dark theme

Respects the system preference, out of the box.

Custom domain and brand

Your logo, colours, fonts and domain. No DeveloperHub branding.

Docs API

Fetch pages, run searches and embed docs inside your product.

2 to 3.2
OpenAPI versions supported, plus Swagger
10+
languages for generated code examples
4.8★
average rating on G2
14 days
free trial, no card required
“We have APIs and SDKs which we monetise through and they need to be explained. My dream is to have them self-serviced, but in order to make them self-serviced, we need to empower our client with the ability to easily integrate.”
Kiran Bali
Kiran Bali
Head of Integrations, Yoti
Read their story →

Point it at your spec.
See what comes back.

Import the OpenAPI file you already have and look at the reference it produces. Fourteen days free, no card, no sales call unless you want one.