Reference

API docs: versions and publishing

An API docs page is a developer portal for your API: an OpenAPI reference, Markdown guides beside it and a version switcher. Everything lives inside a version, and a version is published as one snapshot. This guide covers creating the page, managing versions and publishing. Bringing in the OpenAPI document is described in , writing guides in .
1
Create an API docs page
Log in at , open your team and click
Add Page
. Choose the
API Docs
type, enter a name and an address, then confirm. You land on the
Versions
tab.
2
Add a version
Each version holds its own guides and its own OpenAPI contract. Click
Add version
and fill in:
  • Version slug — for example v1. It becomes the reader URL /v/{slug}/ and is frozen once the version has ever been published: integrators keep it in bookmarks and CI configs.
  • Display name — shown in the version switcher. Freely editable at any time.
  • Description — optional.
The header shows how many versions your plan allows. One version is the default — the one readers land on; pick it with
Make default
in a version's menu.
3
A version's workspace
Opening a version shows its sections:
  • Overview
    — status, reader links and the version settings.
  • Publish
    — what goes out with the next snapshot and the publish controls.
  • Guides
    — the Markdown pages beside the reference.
  • Spec imports
    — every OpenAPI document brought in, with its validation report.
  • History
    — every publication ever built, with rollback.
  • Remote source
    — polling the OpenAPI document from a repository or a URL.
4
Publish
Guides and the contract go live together as one immutable snapshot — there is no “publish this guide”. The
Publish
tab lists what goes out: how many guides are included and which spec import is selected, plus a diff of structural changes against the live contract. Then:
  • Publish
    — the green button carrying the version's display name builds the snapshot and puts it live. Each publication gets a number that only ever goes up.
  • Schedule
    — the snapshot is built right away and goes live at the chosen time, so what ships is exactly what you reviewed. Edits made after scheduling are not included — cancel and schedule again to ship them.
  • Unpublish
    — hides the version from the site.
    Publish again
    builds a fresh snapshot from the current work; “Restore #N” brings back exactly what was live, as a new publication.
After further edits the version shows Published · has changes: readers keep seeing the live publication until the next one.
5
Publication history and rollback
The
History
tab lists every snapshot, newest first, and marks the live one.
Roll back to this
republishes an old snapshot as a new publication — history keeps moving forward, so you can always see what was live when.
6
Deprecate, clone, archive
  • Deprecate
    — tells integrators to move on. The version stays readable and nothing stops working; a notice, and a link to the replacement version if you pick one, appears on every reader page.
  • Clone
    — a new unpublished version with copies of the guides and the same selected spec: the usual way to start v2.
  • Archive
    — takes the version out of navigation, search and the sitemap; its history is kept. A version that has been published cannot be deleted — archive it instead. A never‑published one can be deleted.
7
The "Try it" console
In
Settings
→
"Try it" console
you can let readers send real requests to your API from the reference. Requests go straight from their browser to your servers — the keys they type never reach us. The servers list in your OpenAPI document decides which addresses are reachable, and only https ones are offered. Off by default; GET only unless you also allow POST, PUT, PATCH and DELETE — readers confirm each of those before it fires.

Your first version is live — readers have the reference 🚀

© StatusMate 2022-2026

Регистрационный номер в Реестре программ для ЭВМ 2025690716 от 11.11.2025 г.