Choose the right stored-document processing and export workflow
Stored-document workflows separate three operations: changing a managed document, exporting a snapshot for download or delivery, and processing an input file into a separate output. These operations have different persistence effects. Choose the endpoint and product according to whether the stored source should change or remain intact.
The same processing or export goal across products
| Setup | Process or save stored state | Export or return output | When to use it |
|---|---|---|---|
| Web SDK standalone | Web SDK edits a loaded document in the browser. instance.exportPDF() includes in-progress edits and returns a PDF ArrayBuffer; your application owns durable storage. In Standalone mode, instance.save() saves to the SDK’s local backend, not to durable application storage. | instance.exportPDF() returns a PDF ArrayBuffer for download or upload to your backend. Exporting alone doesn’t store the file remotely. | Use this when your app owns the document source and persistence. |
| Web SDK + Document Engine | In server-backed mode, Web SDK saves supported changes to the Document Engine document. For server-side transformations that should update a stored document, use Document Engine’s document-update operation rather than a file-returning Build request. | Export or download the stored document as a PDF using Web SDK or Document Engine’s PDF download endpoint. The exported file is a result to deliver or store separately; it isn’t itself a new Document Engine document. | Use this when Document Engine manages persistent document state and you need either in-session saves or a server-side document update. |
| DWS Viewer API with DWS-managed documents | DWS Viewer API stores managed documents and persists supported viewer changes. App-provided documents aren’t stored as DWS-managed documents by that flow; your app owns their source and persistence. | Use the DWS Viewer API’s PDF export operation for a managed document or layer. The export response is a file for your application to deliver or store; it doesn’t create another managed document automatically. | Use this when DWS Viewer API manages the source document and viewer state and you need a PDF snapshot of that state. |
| DWS Processor API | DWS Processor API processes the files and instructions supplied with a request; it isn’t a persistent document-management store. | The Build API returns a processed file for your application to store or deliver. For asynchronous jobs, retrieve the result before its documented expiry. | Use this for one-off or automated processing of input files rather than editing a persistent managed document. |
How to choose the right stored-document workflow
Use Web SDK standalone when the browser edits a document but your application owns durable storage. instance.exportPDF() includes in-progress edits and returns the PDF bytes for your application to store or deliver. instance.save() saves changes to the SDK’s local backend; it doesn’t make them durable in your application’s storage.
Use Web SDK with Document Engine when users edit a persistent Document Engine document. In server-backed mode, Web SDK saves supported changes to Document Engine. To perform a server-side transformation and persist it to an existing Document Engine document, use the operation that applies instructions to that document. A normal Build request returns output and doesn’t replace the stored document on its own. Export the stored PDF separately when you need a downloadable snapshot.
Use DWS Viewer API with DWS-managed documents when DWS stores the source and persists supported viewer changes. Export the document or a selected layer as a PDF through the Viewer API when you need a file snapshot. For app-provided documents, DWS session authorization doesn’t transfer ownership of the source or its persistence from your application.
Use DWS Processor API when you want to submit inputs for a processing job and receive an output file. It doesn’t act as a persistent document repository. Store the result in your own application or upload it to a document-management service if it must remain available after the processing workflow.
Common points of confusion
- Save, process, and export are different actions — Saving commits changes to a managed document or application-owned source. Processing creates output from supplied inputs. Exporting produces a file snapshot for delivery; it doesn’t necessarily update the stored source.
- Document Engine Build output doesn’t automatically update its source — Use the Document Engine operation that applies instructions to a stored document when the result should become its state. Use
/api/buildwhen you need a returned output file. - DWS Processor API is document-in/document-out — It processes request inputs and returns output; it doesn’t create a DWS-managed document record for future access. Async result availability is temporary, so retrieve the output before the API-documented expiry.
- PDF export and annotation/state export aren’t the same — A PDF is a rendered document snapshot. Instant JSON or XFDF exports represent annotation or document-record data and require a compatible import or persistence workflow.
- Choose the state to export — Layer-aware workflows may need a specific layer’s PDF rather than the default document output. Confirm which layer or state the chosen endpoint exports.
Typical decision questions
- Is the source already stored in Document Engine or DWS Viewer API, or does your app own the source file?
- Should processing update the stored document, or should it produce a separate output file?
- Do users need a PDF snapshot, structured annotation/state data, or both?
- Which user, layer, or version of the document should the export represent?
- Who stores and delivers the exported file, and how long must it remain available?
- For asynchronous processing, what’s the result expiry, and can your application retrieve it in time?
Guides by product
- Web SDK
- Document Engine
- DWS Viewer API
- DWS Processor API