Choose the right collaboration and synchronization setup
Collaboration and synchronization can look similar in Nutrient Web SDK, Document Engine, and DWS Viewer API, but the responsibility for persistence and real-time updates changes by setup and document source.
The same workflow in each setup
| Setup | What happens to document changes | When to use it |
|---|---|---|
| Web SDK with a license key | Changes stay in the browser until you export, download, or save them through your own custom flow. There’s no built-in multiuser synchronization. | Use this when one user works on a document locally or when collaboration is handled outside Nutrient. |
| Web SDK + Document Engine | Document Engine persists document changes and can synchronize them across users, sessions, and devices. | Use this when you need self-hosted persistence, real-time collaboration, permissions, or cross-platform syncing. |
| DWS Viewer API with DWS-managed documents | DWS Viewer API persists supported document changes and provides managed collaboration and syncing for Web SDK clients. | Use this when you want server-backed collaboration without operating your own Document Engine infrastructure. |
| DWS Viewer API with app-provided documents | DWS Viewer API authorizes and meters the viewer session, while your app remains responsible for the document source and persistence. | Use this when your app already provides the document and doesn’t need DWS to store it as a managed document. |
How to choose the right flow
Use Web SDK with a license key when collaboration isn’t a core requirement, or when your app only needs a single-user editing or review flow.
Use Web SDK + Document Engine when you need your own backend to control document storage, authentication, permissions, and real-time synchronization.
Use DWS Viewer API with DWS-managed documents when you want Nutrient to manage the server-side collaboration stack for you.
Use DWS Viewer API with app-provided documents when your app provides the document directly and only needs DWS Viewer API session authorization and usage metering.
Common points of confusion
- Standalone editing isn’t the same as collaboration — A user can annotate or comment in Web SDK without built-in multiuser synchronization.
- Document Engine is the self-hosted collaboration backend — It provides persistence, synchronization, collaboration state, and permissions for server-backed workflows.
- DWS-managed documents use the managed backend layer — You don’t need to operate your own Document Engine instance to get server-backed persistence or syncing for DWS-managed documents.
- App-provided DWS Viewer API documents are different — DWS Viewer API authorizes and meters the viewer session, but the document isn’t uploaded to DWS as a managed document, so your app controls the document source and any persistence flow.
- Real-time collaboration and persistence are related, but not identical — Changes can be persisted on a server without every connected user necessarily receiving the same live updates in the same way; that depends on the synchronization mode in use.
- Authentication changes by setup — Document Engine typically uses JWTs, while DWS Viewer API uses session tokens for Web SDK clients.
Typical decision questions
Ask these questions before choosing an implementation:
- Do multiple users need to see each other’s changes?
- Do changes need to persist on a server automatically?
- Do you need self-hosted control, or do you want a managed service?
- Do you need permissions or role-based collaboration rules?
- Do you need collaboration beyond the browser across mobile and web clients?
- If you’re using DWS Viewer API, should DWS store and manage the document, or should your app provide it directly?
Equivalent guides by product
- Web SDK
- Document Engine
- DWS Viewer API