Skip to main content
SuperDoc SDKs let you open, read, and edit .docx files from Node.js or Python. They manage the CLI process for you and expose typed methods for every operation.

Installation

The CLI is bundled with the SDK: no separate install needed.

Quick start

The Node SDK supports both ESM and CommonJS:
Set defaultChangeMode: 'tracked' (Node) or default_change_mode='tracked' (Python) to make mutations use tracked changes by default. If you pass changeMode on a specific call, that explicit value overrides the default. The Python SDK also exposes synchronous SuperDocClient with the same document-handle methods when you prefer non-async code paths.

Need file-to-file diffing?

For workflows where you already have Doc1 and need to compare an uploaded Doc2, see Compare documents: a Document Engine workflow that wraps diff.capture, diff.compare, and diff.apply into a recommended file-to-file flow.

User identity

By default the SDK attributes edits to a generic “CLI” user. Set user on the client to identify your automation in comments, tracked changes, and collaboration presence:
The user is injected into every client.open call. If you pass userName or userEmail on a specific client.open, those per-call values take precedence.

Collaboration sessions

Use this when your app already has a live collaboration room. The SDK supports three providers:

Join an existing room (y-websocket shorthand)

Pass collabUrl and collabDocumentId to client.open:
The collabUrl + collabDocumentId shorthand defaults to the y-websocket provider. For Hocuspocus or Liveblocks, pass an explicit collaboration object.

Connect to Hocuspocus explicitly

Use the explicit collaboration object when your server speaks the Hocuspocus protocol:

Forward custom WebSocket query parameters

Attach arbitrary key-value pairs to the WebSocket connection URL with the params field. Use this when your collaboration server expects per-connection metadata (activity tracking, tenant identifiers, feature flags, etc.) that shouldn’t live in the document ID.
Keys and values must both be strings: query parameters serialize as strings on the URL. The field is supported for y-websocket and hocuspocus; Liveblocks manages its transport differently and does not accept this field.
token is reserved: the CLI sets it automatically from tokenEnv. Passing token inside params is a validation error; use tokenEnv for authentication.

Connect to Liveblocks

Liveblocks is configured through an explicit collaboration object. Two auth modes are supported:

Public API key

Auth endpoint

For production use, point to your auth endpoint instead:
Unlike browser usage, SDK authEndpoint values must be absolute URLs (starting with http:// or https://). Relative paths like /api/liveblocks-auth are not supported because the CLI host has no browser origin to resolve them against.
To pass custom headers to your auth endpoint, set authHeadersEnv to the name of an environment variable containing a JSON object of headers:
Environment variables referenced by authHeadersEnv (Liveblocks) and tokenEnv (websocket providers) are resolved inside the CLI host process, not in your application code. If the variable is not already in your shell environment, pass it through the SDK client’s env option as shown above.
Liveblocks input uses roomId. The response normalizes this to documentId:
  • Input: collaboration.roomId
  • Output: openResult.collaboration.documentId

Start an empty room from a local .docx

If the room is empty, pass doc together with collaboration params:
What happens when you pass doc:

Control empty-room behavior

The three onMissing values:
If you reopen an existing ydoc without providing a doc file, the default seedFromDoc will seed a blank document if the room appears empty during sync. This overwrites your existing content. Always use onMissing: 'error' when reopening documents that were previously created or populated.

Check if the SDK seeded or joined

client.open returns a bound document handle. In collaboration mode, bootstrap details are available on the handle’s initial open result:

Available operations

The SDKs expose all operations from the Document API plus lifecycle and client commands. client.open() returns a bound document handle: all document operations run on that handle.

Core

Format

Create

Sections

Lists

Tables

Table of contents

Images

Comments

Track changes

History

Lifecycle

Client

SDK vs browser integration model

The SDKs are request/response wrappers around the CLI. They do not expose browser event subscriptions like editor.on('update', ...) or superdoc.on('editor-update', ...).
  • Call doc.info() at workflow boundaries (after opening, after edits, or before saving), not in a polling loop.
  • If you are building a browser live counter, use the SuperEditor events or SuperDoc events instead.
  • Document API: the in-browser API that defines the operation set
  • CLI: use the same operations from the terminal
  • Collaboration guides: set up Liveblocks, Hocuspocus, or SuperDoc Yjs