Workflows

Content editing and publishing

Create content, save revisioned edits, review generation, and approve an exact delivery version.

On this page

Create and read content

#

Create content with POST /projects/{projectId}/content, a caller-generated requestId, and a prompt. New content uses type: article; its specification chooses a full article or writer brief, funnel stage, and format. Reuse the same creation UUID and payload after an uncertain response.

Creation returns HTTP 200 with data.contentId. Read GET /projects/{projectId}/content/{contentId} to obtain data.document, including contentRevision, contentSnapshotHash, and updatedAt. Read the Studio endpoint for data.studio.brief.briefRevision, sources, proposals, and readiness context.

Save against a revision

#

Document, title, and tag edits use expectedRevision. Brief edits use expectedBriefRevision. Use the value you last read, and read the resulting state before making another dependent edit.

A stale edit returns HTTP 409 with revision_conflict and conflict metadata where available. Re-read the document and reconcile your edit. History and restore endpoints let you inspect a saved version and restore it against the current revision.

Verified public sources can be attached with a replay-protected request ID. Source changes affect readiness; keep sources aligned with the article you will approve.

Generate and review

#

Generation requires write + generate. For an empty document, first call POST /content/{contentId}/questions with {}. This deterministic setup step requires write and returns data.questions. Answer all three questions using the returned choices, including one current target-length choice.

Send those three answers to POST /content/{contentId}/generation with a new request UUID and the expected document revision. Initial generation does not accept a revision instruction. The illustrated answers match the full-article topic-guide setup; use your content project's returned questions and choices.

Once a draft exists, request a revision with an instruction and answers: [] to retain its current assignment. An optional block scope must name a block that still exists. HTTP 202 returns data.generation.jobId and its state. A newly queued job is pending; replay can return its existing state. Acceptance is not completion.

Poll GET /projects/{projectId}/content/{contentId}/generation/{jobId} with read. The job ID appears as data.generation.id in that response. Status is pending, claimed, completed, or failed. A result can include a proposal to review rather than an already-applied edit.

Read the Studio context, inspect the proposal, and send an accepted or rejected decision against the expected revision. Then re-read the document before the next step. All nested content paths begin with /projects/{projectId}.

Readiness and exact-version approval

#

Run POST /content/{contentId}/readiness against the document's current revision and snapshot hash. This records readiness for the saved article and sources. Correct the reported blockers before approving.

Approval requires write + publish. Send the document's updatedAt as expectedUpdatedAt and its snapshot hash as expectedHash to POST /content/{contentId}/approval. Its result includes data.publishing, with the current version and whether approval is current. A changed document cannot inherit approval for an earlier version.

All nested content paths also begin with /projects/{projectId}. Writer briefs are reviewed and exported; they are not eligible for Webflow publication.

Queue and verify provider delivery

#

Read the approved data.publishing.currentVersion.id and hash, then call POST /content/{contentId}/publishing with that version, expectedHash, and action: draft or publish. Webflow must be connected and configured; live delivery also depends on its enabled controls.

HTTP 202 means delivery was accepted. Poll GET /content/{contentId}/publishing and inspect the actual approval, publication, current draft, live delivery, and destination facts. Delivery to a prior destination does not establish that the current destination is live. Retry only an eligible job through the retry endpoint.

Content deletion preserves active-job and publication boundaries. Archiving changes the content workflow state; it is not a command to erase provider delivery history.

API documentation