For developers, DeveloperHub
Solutions · Developers

Write docs where you
already write code.

Two-way Git sync, an MCP server your assistant can publish through, and DeveloperHub's own checks on every pull request. Docs get the pipeline the rest of your stack already has, without a static site generator to babysit.

OpenAPI 3.2MCP server14-day trial See a live demo →

Not everyone on the team wants a terminal. The writers' side of the same workspace →

acme/api · docs/rate-limits Docs CI
checks on pull request
 
01 · Docs-as-code

Drafts are branches. Reviews are PRs.

Native two-way GitHub sync. Edit in the app or in your editor and push: changes flow both ways, and neither side wins by overwriting the other. Nothing half-written reaches production, because work in progress is just a branch.

Explore documentation features →
Bidirectional, on every push

No custom GitHub Actions to wire up and no YAML to maintain. The sync is native and it works out of the box.

Checks that block bad merges

Broken links, missing pages and OpenAPI errors are caught on the PR, not by a reader three weeks later. Every pull request against the docs repo gets the same treatment.

Review with your own rules

Same reviewers, same branch protection, same merge queue. Docs stop being the exception in your process.

Local
You push a branch
Your editor, or the app
Sync
Docs sync both ways
Native, no Actions
Checks
The PR is validated
Links, pages, OpenAPI
Review
Reviewed like code
Comments, approvals
Live
Docs go live
On merge, or on a click

It watches the other repo too. Open a pull request on the product itself and the agent starts a changeset for the docs it affects, waiting in the editor for a writer to approve. Opening the pull request back to you is coming soon.

Import and export are the same story: pull the whole project out as editable files, mass-edit them offline, push the repo back, and let the sync do the reconciling. Nothing about this platform is a one-way door.

02 · API references

OpenAPI in. A reference people can actually use, out.

Upload OpenAPI 2, 3, 3.1, 3.2 or Swagger and the whole reference renders itself: authentication methods, request and response schemas, property constraints, enums, and code snippets generated in 10+ languages. A live try-it playground sits on every endpoint.

Auto-generated from your spec, so documenting an endpoint costs no developer time
Snippets in curl, Python, Node, Go, PHP, Ruby, Java and more, regenerated on every change
Schemas, constraints, enums and auth rendered from the spec, not retyped by hand
Explore API docs →
GET /v1/payments/{id} Try it →

Retrieve a payment by ID. Returns the full transaction, including status, amounts and metadata.

Path parameters
idstringrequired
Response 200 OK
idstring
amountinteger
currencystring
statusenum
curlPythonNodeGo 10+ languages
curl https://api.acme.dev/v1/payments/pay_42 \ -H "Authorization: Bearer $ACME_KEY"
03 · Your stack

Four integrations you would otherwise have built yourself.

The MCP server, the playground, the spec editor and the CI hook all ship in the box. No plugin store, no half-maintained community action, no bespoke pipeline that only one person understands.

Editor MCP server

Publish from Claude, Cursor, Codex or your terminal.

Point any MCP client at your project and create, edit and publish pages from the chat. Every request gets your full docs context, so drafts land on brand, in the right section, and consistent with what you already shipped.

> draft a quickstart for the payments API
  read 12 pages of project context
  developerhub.create_page ...
  ✓ published to docs.acme.dev/payments
API editor

Edit OpenAPI without knowing OpenAPI.

Visual, Split and Source views over the same spec, with live linting in all three. Hand it to someone who has never opened a YAML file and they will still ship a valid endpoint.

VisualSplitSource ✓ 0 issues
▾ /payments
  GET /payments/{id}
  POST /payments
▸ /refunds
MethodGET
SummaryGet a payment
Tagpayments
Authbearer
Try the free API editor →
API playground

Real requests, from inside the docs.

Authentication, headers and parameters pre-filled from your spec, OAuth 2.0 flows built in. Readers fire a real call in seconds instead of rebuilding it in Postman, which is the fastest support deflection you will ever ship.

GET/v1/users/profile
Authorization: Bearer sk_live_•••••
200 OK98ms
{ "id": "usr_42", "plan": "grow" }
CI/CD

Push the spec on every build.

Send your updated OpenAPI definition straight from the pipeline and the reference regenerates itself. No manual uploads, no stale endpoints, and roughly five hours back per release that used to go on copy and paste.

acme/api · build #1421 · main
openapi.yaml pushed from CI
15 endpoints refreshed
Snippets regenerated in 10+ languages
Docs live at docs.acme.dev
04 · The rest of it

More power under the hood.

The parts that do not need a demo, but that you will use every week.

Code steps

Numbered walkthroughs with synced multi-language code blocks.

Custom CSS and JS

Override any rule. Nav buttons, blur effects, custom icons, your call.

Versioning

Clone a version and ship it alongside the old one. Links migrate themselves.

Import and export

Editable files out, mass-edit offline, push back through Git.

Private docs

SSO, email invites, secure links or JWT custom login.

Integrations

Google Analytics, Intercom, Slack, plus any custom JS.

Docs API

Search your docs and embed them inside your own product.

Custom domain

docs.acme.dev, or acme.dev/docs on a subdirectory.

How we handle security → DeveloperHub vs ReadMe → vs Mintlify →

“3 projects later, we do confirm that DeveloperHub is THE choice for API documentation sites. It helps us to effortlessly create (and more importantly keep it up-to-date!) our evolving API reference, backed by world-class support.”

Victor Martin
Victor Martin
Chief Technology Officer, iBroker

Put your docs in the
same pipeline as your code.

Connect a repo, open a pull request, and watch the checks run. Fourteen days free, no card, no sales call unless you want one.