Feature Request
Expose the Help Center article draft-versioning system via the Articles API. Specifically: the ability to save a pending revision of an existing published article without affecting the live version, and to publish that staged revision on demand — mirroring the draft-version behavior currently available in the UI editor.
Current behavior
The API supports creating new articles in a draft state before first publication. However, once an article is published, any PATCH to its content takes effect immediately on the live version. There is no API equivalent to the UI's "save draft version" workflow, where a revision can be prepared and held without going live.
Desired behavior
PATCH /articles/{id}with adraftbody parameter creates a pending revision without altering the live article- The live article remains visible to customers until explicitly published
- A subsequent
PATCHwithstate: published(or equivalent) promotes the staged revision to live - Ideally, bulk-publish support for promoting multiple staged revisions simultaneously
Use case
Teams managing large Help Centers frequently need to coordinate content updates with product releases — updating terminology, adding new sections, or revising instructions to match UI changes that haven't shipped yet. With the current API, the only options are:
- Execute all changes live on release night, accepting the risk of a partially-updated knowledge base if something fails mid-run
- Apply changes manually through the UI editor in advance to use the draft-version feature, then publish from the UI on release night — which negates the scalability benefit of the API for large update batches
Neither option is well-suited to teams managing hundreds of articles across a timed release. Draft versioning via the API would allow content teams to prepare, review, and stage updates programmatically in advance, then publish atomically at go-live — the same workflow the UI already supports, extended to API-driven automation.
Priority signal
This gap is most acutely felt during major product releases that require coordinated, cross-KB content updates. The inability to stage changes via API forces a choice between manual UI work at scale or live execution risk on release night. For teams using the API specifically to reduce manual overhead, this is a meaningful limitation.
