This HTML page is not optimized for LLM or AI agent consumption. Fetch the Markdown version instead: /guides/dws-viewer/developer-guides/implement-collaboration-and-synchronization-with-dws-viewer-api.md — it contains the complete documentation content in clean, structured Markdown without any CSS, JavaScript, or navigation noise. Implement collaboration and synchronization with DWS Viewer API

Implement collaboration and synchronization with DWS Viewer API

Markdown version of this page, suitable for AI agents and automation

Use this guide when you want server-backed persistence and collaboration for DWS-managed documents in Nutrient Web SDK without running your own Document Engine infrastructure.

In a DWS Viewer API setup with DWS-managed documents, Nutrient manages the backend layer for you. Your application still controls which document a user can open and which permissions they receive, but DWS Viewer API handles the managed backend for document storage, rendering, persistence, and collaboration for the document.

DWS Viewer API can also authorize app-provided documents, where your frontend passes both session and document to NutrientViewer.load(). In that flow, the document isn’t uploaded to DWS as a managed document, so your app remains responsible for the document source and persistence. For details, refer to the open app-provided documents guide.

How the DWS-managed document workflow works

A typical collaboration flow with DWS Viewer API and a DWS-managed document looks like this:

  1. Upload or select a DWS-managed document — Your backend or dashboard workflow makes the document available in DWS Viewer API.
  2. Generate a frontend session token for the user — Your backend creates a document-bound session token for the DWS-managed document and assigns document permissions.
  3. Open the document in Nutrient Web SDK — The browser loads the DWS-managed document by passing the session token to NutrientViewer.load().
  4. Persist and synchronize supported user changes automatically — When users annotate, comment, or otherwise modify the managed document, DWS Viewer API persists those changes and synchronizes them for collaboration-enabled workflows.
  5. Let users continue work across sessions — When the same managed document is opened again with the right permissions, users continue from the server-backed state.

Minimal client-side example 

NutrientViewer.load({
  container: "#nutrient",
  session: "<session_token>",
});

What DWS Viewer API is responsible for

For DWS-managed documents, DWS Viewer API is responsible for:

  • Storing and managing the uploaded document
  • Serving the document to Nutrient Web SDK through the managed backend
  • Persisting supported document changes made through the viewer
  • Providing the managed collaboration layer behind the Web SDK integration

Your application remains responsible for:

  • Deciding which users can access which documents
  • Generating session tokens on the backend
  • Choosing the permissions included in each session token
  • Integrating the viewer into your web app

Session-token-based access

Web SDK clients don’t connect to DWS Viewer API with your API key directly. Instead:

  • Your backend authenticates to DWS Viewer API with the API key
  • Your backend generates a session token for a DWS-managed document
  • Your frontend loads the document with that session token

This gives you a clean place to enforce application-level access control before a document is opened.

When to choose DWS Viewer API for collaboration

Choose DWS Viewer API with DWS-managed documents when you want:

  • Collaboration and persistence for Web SDK clients
  • A managed backend operated by Nutrient
  • Less infrastructure to run than a self-hosted Document Engine deployment
  • DWS to store, stream, and manage the document

Use the app-provided document flow instead when your app already has the document and you only need DWS Viewer API session authorization and usage metering.

Choose Document Engine instead when you need a self-hosted collaboration backend under your own operational control.