Skip to main content
A version is a frozen copy of an article’s title, content, and language taken at a specific point in the article’s history. Versions exist so you can audit edits and roll back to a prior body when a change goes wrong.

How versions are written

There are two paths into the version log. Both append immutable rows to the article’s history.

Auto-snapshots on PATCH

Every PATCH /articles/{id} that changes title or content snapshots the previous state before the new values land. The snapshot’s change_summary is "Auto-snapshot before API update". You don’t have to do anything to opt in — auto-snapshotting is the default for the API surface, so any edit is reversible.
A PATCH that only touches metadata (status, visibility, category, language, tags) does not create a snapshot — the body didn’t change.

Manual snapshots

POST /articles/{id}/versions writes a version from the article’s current state. Use this when you want to mark a checkpoint that didn’t ride along with an edit — e.g. before a risky bulk PATCH, or to annotate a published version with a meaningful change_summary.

The version object

integer
required
Monotonically increasing per article, starting at 1. Gaps don’t appear; deletes aren’t supported.
string
required
The language tag the article carried when the snapshot was taken. A snapshot captures one language at a time — the primary article’s language. Translations are not versioned through the API.
string | null
Free-form note attached to the snapshot. For auto-snapshots this is set to "Auto-snapshot before API update"; for manual snapshots it’s whatever you passed in the body.

Listing and reading

GET /articles/{id}/versions is paginated (page, page_size). GET /articles/{id}/versions/{version} reads one by its integer version_number.

Restoring a prior version

POST /articles/{id}/versions/{version}/restore copies the version’s title and content back into the live article. The article’s current state is snapshotted first, so the restore is itself reversible — you can roll the restore back by restoring the snapshot it created.
The response is the article in its restored state. If the article was published at the time of the restore, the indexing pipeline re-runs against the restored body — you’ll see indexing_status move back through pending → processing → indexed, and the article.indexed webhook fires when it lands.
Restoring a published article requires the articles.publish scope (in addition to articles.manage), because the live, indexed body is being overwritten. API keys are org-wide so this matters only for OAuth tokens.

Limitations

  • Versions are immutable. There is no PATCH or DELETE endpoint for an article_version.
  • Versions snapshot the primary language only. Translations are not versioned through the API.
  • Deleting an article deletes all of its versions.