Create draft and patch document
Create a new draft on the published document and apply the patch in one call. There is no auto-publish — the response includes the new draftIdentifier for follow-up calls. Pass an optional branchId to attach the draft to a branch; omit it for a draft on the main (unpublished) workspace.
Draft → publish workflow
Editing an existing document is a three-step flow:PATCH /api/v2/documents/{documentId}/draft(this endpoint) — creates a new draft on the published document and applies your patch. Returns the newdraftIdentifier.- (optional)
PATCH /api/v2/documents/{documentId}/draft/{draftId}— apply further patches to that draft. POST /api/v2/documents/{documentId}/draft/publish— publish the main draft live.
409 — patch the existing draft (step 2) or publish/discard it first. This replaces v1’s clearExistingDraft flag, which does not exist in v2.
A GET response is a valid PATCH body — read the current state, edit it, and submit it back verbatim.
Field constraints
| Field | Limit | Error (400) |
|---|---|---|
name (document) | 1–254 characters | name cannot be empty · name must be 254 characters or fewer |
summary | 1–255 characters, optional | summary cannot be empty · summary must be 255 characters or fewer |
queryPresentations.data.{key}.name | 1–144 characters | name must be 144 characters or fewer |
queryPresentations.data.{key}.subTitle | ≤ 250 characters | subTitle must be 250 characters or fewer |
queryPresentations.data.{key}.description | ≤ 500 characters | description must be 500 characters or fewer |
queryPresentations.data | ≤ 48 non-null entries per patch | A single patch may carry at most 48 query presentations. |
summary is an audit-trail note describing the change (never returned by reads); when omitted the server generates one from the touched sections. Null queryPresentations.data entries (deletions) do not count toward the 48-entry cap.
Addressing tiles (no miniUuid)
Tiles are addressed by their record key in queryPresentations.data (e.g. "2"). The server owns internal tile identity, so you never send or manage miniUuid:
- New key → a new tile is created.
- Existing key, identical content (a verbatim round-trip of a
GET) → treated as a no-op and dropped from the patch. - Existing key, changed content → the tile is updated (the server regenerates its internal identifier).
linked-type tabs always re-resolve — they are excluded from no-op detection.- Query presentations are immutable server-side: replace a tile by key, don’t mutate it in place.
data is shallow-merged by key — omitted keys are untouched; data.{key}: null deletes that tile. order, when present, replaces the tab order. controls and settings are likewise shallow-merged; containers, when present, fully replaces the layout.
AI summaries via linked tiles
There is nonarrative field. To attach an AI-style summary that reuses another tile’s query, add a linked-type query presentation whose sourceQueryPresentationKey points at the source tile’s record key (a string such as "2" — not a positional index into order):
Authorizations
Can be either an Organization API Key or Personal Access Token (PAT).
Include in the Authorization header as: Bearer YOUR_TOKEN
Path Parameters
The published document's URL slug (e.g. abc123) or its canonical workbook UUID.
Body
The draft-route patch body plus an optional branchId selecting the branch the new draft is attached to.
Branch the draft is created on. Omit for a draft on the main (unpublished) workspace.
Document name.
1 - 254Document description.
Caller-supplied description of what this patch changes, written to the history audit trail. When absent, the server generates one from the touched sections.
1 - 255Query presentations (tabs/tiles) keyed by record key.
Dashboard filters/controls keyed by control ID.
Document settings. Shallow-merged with the existing settings.
Container layout. When present, fully replaces the existing layout.