Choose the right layers and versioned document state setup
Layers and versioned document state can look similar across Nutrient Web SDK, Document Engine, and DWS Viewer API, but the meaning of a layer and the owner of the state change depending on the setup.
The same concept in each setup
| Setup | How layers or versioned state work | When to use it |
|---|---|---|
| Web SDK with a license key | Your app can manage separate annotation or review states, but Nutrient doesn’t provide built-in server-backed layer persistence. | Use this when one user works locally or when your app owns how versioned state is stored and restored. |
| Web SDK + Document Engine | Document Engine persists document state per Instant layer and can synchronize those layers across users, sessions, and devices. | Use this when you need self-hosted server-backed layers, permissions, or multiple perspectives on one document. |
| DWS Viewer API with DWS-managed documents | DWS Viewer API persists document state per DWS layer for managed documents and can scope sessions to a specific layer. | Use this when you want managed server-backed layers without operating your own Document Engine infrastructure. |
| DWS Viewer API with app-provided documents | DWS Viewer API can authorize a browser session, but your app remains responsible for the document source and any versioned state. | Use this when your app provides the file directly and doesn’t need DWS to store or manage separate review state. |
How to choose the right setup
Use Web SDK with a license key when your app already owns persistence and you only need local or app-managed alternate document states.
Use Web SDK + Document Engine when you need self-hosted server-backed layers, shared state, reviewer isolation, or permissions on top of multiple document perspectives.
Use DWS Viewer API with DWS-managed documents when you want Nutrient to manage the server-backed layer model for you.
Use DWS Viewer API with app-provided documents when your app provides the document directly and you only want DWS Viewer API session authorization, not DWS-managed state.
Common points of confusion
- Instant layers are not PDF Optional Content Group (OCG) layers — Instant layers are server-backed collaboration state. OCG layers are PDF content visibility layers inside the file itself.
- A layer is usually a workflow boundary, not a new uploaded document — In Document Engine and DWS Viewer API, multiple review states can exist on top of one underlying document.
- Reviewer isolation is one common layer use case — Separate layers can represent different reviewers, teams, or perspectives on the same file.
- Layer creation differs by setup — In Document Engine, layers are typically part of the Instant/Document Engine workflow. In DWS Viewer API, a layer can be explicitly created through the API or effectively materialized on first write when a session is scoped to it.
- App-provided DWS documents are different — DWS Viewer API can authorize the viewer session, but if the document isn’t DWS-managed, your app still owns versioned state and persistence decisions.
Typical decision questions
Ask these questions before choosing a layers strategy:
- Do multiple users need separate review state on the same underlying document?
- Should those separate states persist automatically on a server?
- Do you need self-hosted control, or do you want a managed service?
- Do users need permissions or visibility rules tied to a layer?
- Does your app already store alternate document states, or do you want Nutrient to own that model?
Equivalent guides by product
- Web SDK
- Document Engine
- DWS Viewer API