Create and edit documents

Create, update, and delete rich-text Documents and Wiki pages in a workspace, including the content/contentBase64 split and the anti-wipe guard.


Use the createDocument, updateDocument, and deleteDocument mutations to manage the lifecycle of a rich-text document — a collaboratively-edited page that lives inside a workspace. Workspaces are Project objects in the API, and each document is a Document. The same Document row powers both regular documents and Wiki pages: set wiki: true on create to make it a Wiki page.

A document carries two content representations. content is the rendered HTML. contentBase64 is the base64-encoded collaborative-editing snapshot (the Yjs binary state the editor syncs over WebSocket). When you create a document from the API, sending content is usually enough; contentBase64 is for clients that maintain their own collab state.

This page covers rich-text documents only. The separate Portable Document subsystem (PDF templates for printing record data) is documented under Build Portable Document templates.

Request

Create a document in a workspace. projectId is the only required field; everything else is optional.

mutation CreateDocument {
  createDocument(
    input: {
      projectId: "project_123"
      title: "Onboarding runbook"
      content: "<h1>Onboarding runbook</h1><p>Step 1…</p>"
    }
  ) {
    id
    title
    wiki
    createdAt
  }
}

To create a Wiki page instead, set wiki: true:

mutation CreateWikiPage {
  createDocument(input: { projectId: "project_123", title: "Team handbook", wiki: true }) {
    id
    title
    wiki
  }
}

Parameters

CreateDocumentInput

ParameterTypeRequiredDescription
projectIdString!YesID or slug of the workspace (Project) the document belongs to.
titleStringNoDocument title. Defaults to an empty string if omitted.
contentStringNoDocument body as HTML. Defaults to an empty string if omitted.
contentBase64StringNoBase64-encoded collaborative-editing snapshot. Leave unset unless your client manages its own collab state.
wikiBooleanNoWhen true, the document is a Wiki page instead of a regular document. The workspace must have the corresponding feature enabled (see Permissions).

Response

{
  "data": {
    "createDocument": {
      "id": "clm4n8qwx000008l0g4oxdqn7",
      "title": "Onboarding runbook",
      "wiki": null,
      "createdAt": "2026-05-29T10:12:04.000Z"
    }
  }
}

Document

The fields available on the returned Document type.

FieldTypeDescription
idID!Unique document identifier.
uidString!Short stable identifier used in URLs.
titleString!Document title.
contentStringDocument body as HTML.
contentBase64StringBase64-encoded collaborative-editing snapshot.
wikiBooleantrue if this is a Wiki page; otherwise null/false.
projectProject!The workspace the document belongs to.
createdByUser!The user who created the document.
createdAtDateTime!When the document was created.
updatedAtDateTime!When the document was last modified.

Update a document

Use updateDocument to change a document’s fields. Only id is required — include just the fields you want to change. A title-only edit passes through without touching content.

mutation UpdateDocument {
  updateDocument(
    input: {
      id: "document_123"
      title: "Onboarding runbook (v2)"
      content: "<h1>Onboarding runbook</h1><p>Updated.</p>"
    }
  ) {
    id
    title
    updatedAt
  }
}

UpdateDocumentInput

ParameterTypeRequiredDescription
idID!YesID of the document to update.
titleStringNoNew title.
contentStringNoNew HTML body.
contentBase64StringNoNew collaborative-editing snapshot. Subject to the anti-wipe guard below.
wikiBooleanNoFlip the document between document and Wiki page. The caller must have permission for both the current and the resulting type.
userIdStringNoService-only attribution field used by Blue’s collaboration server. Not for client use — it is validated server-side and rejected on regular calls. See Permissions.
Anti-wipe guard

If contentBase64 is provided and decodes to empty (or undecodable) collab state while the document already has real content, updateDocument rejects the call with BAD_USER_INPUT rather than blanking the document. This protects against a stale or disconnected client overwriting good content. Title-only updates (no contentBase64) are never affected.

Delete a document

Use deleteDocument to delete a document by ID. It returns Booleantrue on success — so it takes no sub-selection. The deleted document is moved to trash, not hard-deleted.

mutation DeleteDocument {
  deleteDocument(id: "document_123")
}
{ "data": { "deleteDocument": true } }

Errors

CodeOperationWhen
PROJECT_NOT_FOUNDcreateDocumentNo workspace matches projectId.
DOCUMENT_NOT_FOUNDupdateDocument, deleteDocumentNo document matches id.
FORBIDDENallThe caller isn’t an ADMIN/OWNER/MEMBER on the workspace, or the workspace doesn’t have the docs (or wiki) feature enabled for the caller’s role.
BAD_USER_INPUTupdateDocumentThe anti-wipe guard rejected a contentBase64 that would blank existing content, or a service call supplied a userId that doesn’t resolve to a real user.
RATE_LIMITEDcreateDocumentMore than 5 createDocument calls in the 60-second window for the same user (default limit).
UNAUTHENTICATEDallThe request carries no valid credentials.

Permissions

  • createDocument requires the caller to be an ADMIN, OWNER, or MEMBER on the workspace, and the workspace must have the relevant feature enabled for that role: the docs feature for a regular document, or the wiki feature when wiki: true. It is rate-limited to a default of 5 requests per 60 seconds per user.
  • updateDocument and deleteDocument require the caller to have permission for the document’s type (docs for documents, wiki for Wiki pages). For an update that flips wiki, the caller needs permission for both the current and the resulting type. deleteDocument also succeeds for the document’s original creator.
  • updateDocument additionally accepts internal Blue service callers. The userId field exists only for that path — Blue’s collaboration server passes it to attribute an edit to the right user. The server validates it against a real User and rejects it otherwise, so regular API clients should never set it; the editing user is taken from your credentials.