.png)
DocuWare Integration Guide
Connect DocuWare documents, file cabinets, metadata, and selected event notifications with enterprise applications through its Platform REST API and Martini workflows.
DocuWare integration options at a glance
DocuWare primarily integrates through its Platform REST API, which provides access to organizations, File Cabinets, Documents, Document Index Fields, Dialogs, and workflow-related resources. Martini can consume these HTTP endpoints to search, retrieve, store, update, and route documents, including multipart requests for applicable file operations. DocuWare also supports webhook-style notifications for selected events, allowing Martini to receive an identifier, retrieve the authoritative resource, and continue processing in a workflow. OAuth 2.0 is preferred for new integrations where supported, with organization context and permissions applied to API access. Scheduled, paginated synchronization is appropriate when event coverage is limited.
| Integration point | Supported by DocuWare? | Common use cases | How Martini supports it |
|---|---|---|---|
| Platform REST APIs | Yes | Search, retrieve, create, update, move, or delete Documents where permissions allow, and access Organizations, File Cabinets, Dialogs, indexes, and workflow-related resources. | Martini can consume DocuWare HTTP endpoints, map JSON or XML responses, construct query parameters and multipart requests, and orchestrate multi-step workflows. |
| Webhooks / outbound callbacks | Limited | Receive notifications for selected DocuWare events or resources. Coverage is not universal across documents, indexes, users, configuration, and workflows. | Martini can expose an HTTP API or workflow trigger, validate the notification, retrieve the current DocuWare resource, and route the event for downstream processing. |
| File and document content APIs | Yes | Upload or store documents, retrieve file content, process document sections, and work with metadata separately from binary content where supported. | Martini can handle multipart requests, validate content type and size, transform metadata, and deliver content to other applications or repositories. |
| Authentication | Yes | Authenticate API access with OAuth 2.0 and bearer access tokens where supported, while applying organization context and DocuWare user or application permissions. | Martini can keep client credentials, tokens, organization settings, and environment-specific configuration in secure secrets and invoke authenticated API workflows. |
| Pagination and incremental retrieval | Yes | Process paginated document searches and implement incremental archive synchronization using available document metadata, timestamps, and checkpoints. | Martini can loop through pages, control concurrency, persist checkpoints, and apply deterministic identifiers to prevent duplicate processing. |
| Bulk / asynchronous APIs | Not confirmed | A universal bulk or asynchronous API covering all DocuWare resources was not confirmed; high-volume work should use pagination and controlled processing. | Martini can implement bounded, scheduled batches with retries, checkpoints, and workflow-level error handling without assuming a universal bulk endpoint. |
| Database access | Not confirmed | Direct access to the DocuWare internal database was not confirmed and should not be treated as a supported integration interface. | Martini should use the official Platform API rather than direct database connectivity for DocuWare data. |
How DocuWare exposes data and business events
DocuWare REST APIs
The DocuWare Platform REST API is the primary integration surface. It exposes HTTP resources for Organizations, File Cabinets, Documents, Document Index Fields, Dialogs, and workflow-related operations, with JSON or XML representations and multipart requests for applicable content operations.
Martini implementation pattern
Martini implementation pattern: Martini authenticates to DocuWare, calls the required resource endpoints, handles pagination and multipart content, maps responses into canonical models, and orchestrates writes to downstream systems. API errors are classified so transient failures can be retried without repeating completed document operations.
Implementation sequence
DocuWare Webhooks
DocuWare supports webhook-style notifications for selected platform events and resources. These notifications do not represent a universal event stream, so the required event and deployment coverage must be confirmed before implementation.
Martini implementation pattern
Martini implementation pattern: Martini exposes an authenticated HTTP endpoint or workflow trigger, validates the notification, acknowledges it promptly, and retrieves the current Document or Workflow Task from DocuWare before performing longer downstream processing. This avoids treating a limited event payload as the authoritative business record.
Implementation sequence
DocuWare File Content APIs
DocuWare Documents include file content and document sections. The Platform API supports storing and retrieving document content, with multipart requests commonly relevant when sending files and associated metadata.
Martini implementation pattern
Martini implementation pattern: Martini validates filename, content type, size, required index values, and source identifiers before creating or updating a Document. It can route retrieved content to an approved downstream application while keeping binary payloads and operational logs appropriately protected.
Implementation sequence
Common DocuWare integration patterns
Pattern 1: File documents from business applications
When to use this pattern
Use this pattern when Salesforce, Microsoft Dynamics 365, SAP, DocuSign, or another upstream application needs to archive a document in a DocuWare File Cabinet. It combines binary content with validated business metadata and protects against duplicate storage.
Integration direction
Example Mapping
| DocuWare Field | Canonical Field | Target Field |
|---|---|---|
| sourceDocumentId | externalDocumentId | Document Index Field: ExternalDocumentId |
| customerNumber | customerReference | Document Index Field: CustomerNumber |
| documentType | documentType | Document Index Field: DocumentType |
| fileContent | documentContent | Document file content |
Martini implementation pattern
Martini receives the source payload, validates required metadata and file properties, searches for an existing matching external identifier where feasible, maps fields to the selected File Cabinet, and submits a multipart request to DocuWare. It stores the resulting Document identifier and uses bounded retries for transient failures while routing validation or permission errors for review.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Retrieve documents for an application
When to use this pattern
Use this pattern when an application needs document metadata or file content based on a customer number, invoice number, contract number, document type, or other business identifier. It provides a controlled API rather than direct access to DocuWare.
Integration direction
Example Mapping
| DocuWare Field | Canonical Field | Target Field |
|---|---|---|
| customerNumber | customerReference | DocuWare search criterion |
| invoiceNumber | documentReference | Document Index Field: InvoiceNumber |
| documentType | documentType | Document Index Field: DocumentType |
| fileContent | documentContent | Application file response |
Martini implementation pattern
Martini exposes an application-facing API, validates and authorizes the request, searches the relevant File Cabinet or Dialog, retrieves matching Documents and content, and returns only the permitted result. It handles no-match and multi-match rules explicitly and avoids logging document binaries or access tokens.
Martini capabilities used
- API exposure
- API consumption
- data mapping
- authorization
- error handling
Pattern 3: Process selected DocuWare events
When to use this pattern
Use this pattern when a required DocuWare document or workflow event is covered by the tenant's webhook capabilities. It is useful for routing newly relevant documents, retrieving authoritative state, and invoking downstream systems without polling every resource continuously.
Integration direction
Example Mapping
| DocuWare Field | Canonical Field | Target Field |
|---|---|---|
| resourceId | docuwareResourceId | Downstream correlation ID |
| eventType | eventType | Routing rule |
| documentIndexFields | documentMetadata | Downstream document metadata |
| documentContent | documentContent | Downstream file or archive |
Martini implementation pattern
Martini receives and validates the notification, acknowledges it promptly, retrieves the current resource from DocuWare, and applies event-specific routing and authorization rules. Idempotency keys and persisted processing status prevent duplicate downstream actions, while transient API failures follow bounded retry policies.
Martini capabilities used
- workflows
- API exposure
- API consumption
- business rules
- error handling
- monitoring
Pattern 4: Synchronize archived documents incrementally
When to use this pattern
Use this pattern for scheduled archive synchronization when webhook coverage is unavailable or incomplete. It processes paginated searches, exports metadata or content to another repository or business application, and resumes from a durable checkpoint.
Integration direction
Example Mapping
| DocuWare Field | Canonical Field | Target Field |
|---|---|---|
| DocumentId | sourceDocumentId | External document key |
| ModifiedDate | lastChangedAt | Checkpoint and target timestamp |
| Document Index Fields | documentMetadata | Repository metadata |
| fileContent | documentContent | Repository file |
Martini implementation pattern
A scheduled Martini workflow queries DocuWare incrementally, follows all result pages, retrieves the required content, maps metadata, and writes to the target repository. It records checkpoints and deterministic identifiers, controls concurrency, retries transient failures, and isolates malformed documents for later remediation.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination
- data mapping
- checkpointing
- error handling
Applications commonly integrated with DocuWare
DocuWare can be integrated with adjacent business applications to archive documents, associate document references with business transactions, and automate document-driven workflows. The exact objects, permissions, and event coverage depend on each product's configuration.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Archive customer correspondence, signed agreements, service documents, and sales records in DocuWare while making document references available from Salesforce. | Salesforce → Martini → DocuWare | Martini receives Salesforce business data or document content, validates required identifiers, maps metadata to DocuWare Document Index Fields, and stores the document in the selected File Cabinet. A reverse workflow can search DocuWare and return document links or content to Salesforce with retries and duplicate checks. |
| Microsoft Dynamics 365 | Store invoices, purchase orders, customer documents, and finance records in DocuWare while synchronizing document references with Dynamics 365. | Microsoft Dynamics 365 → Martini → DocuWare | A Martini workflow orchestrates Dynamics 365 requests and DocuWare REST calls, maps customer and transaction identifiers to index fields, stores document content separately from metadata, and persists the DocuWare Document identifier for later updates. |
| SAP | Archive invoices, procurement documents, delivery records, and other SAP-associated business documents in DocuWare. | SAP → Martini → DocuWare | Martini accepts SAP-originated document data through the available SAP interface, applies validation and business rules, transforms SAP identifiers into DocuWare index values, and uploads the document using the Platform API with controlled retries. |
| Microsoft 365 | Capture documents from Microsoft-based business processes, classify them in DocuWare, and expose DocuWare document references to downstream Microsoft workflows. | Microsoft 365 → Martini → DocuWare | Martini coordinates Microsoft 365 and DocuWare API calls, separates binary content from index metadata, applies File Cabinet-specific validation, and returns a stable DocuWare identifier or document reference to the Microsoft process. |
| DocuSign | Store completed agreements and signing evidence in DocuWare with index fields such as signer, contract number, and completion date. | DocuSign → Martini → DocuWare | Martini receives the completed agreement through the available DocuSign API configuration, validates the signing status and file payload, maps agreement metadata to Document Index Fields, and stores the content in the appropriate File Cabinet. |
| Jira | Archive project approvals, technical documents, or delivery records in DocuWare and attach DocuWare references to Jira issues. | Jira → Martini → DocuWare | A Martini workflow maps Jira issue keys and project metadata to DocuWare index fields, stores or retrieves documents through the Platform API, and updates the Jira issue with a controlled document reference after successful processing. |
| Workday | Archive HR or finance-related documents from Workday processes in DocuWare, subject to data-protection and access-control requirements. | Workday → Martini → DocuWare | Martini receives permitted Workday document data, applies privacy and authorization rules, maps business identifiers to DocuWare index fields, and stores content using environment-specific credentials and auditable workflow outcomes. |
How to build a DocuWare integration in Martini
Objective
Establish secure, environment-specific access to DocuWare and define the organization, File Cabinet, Dialog, and permission context required by the integration.
Instructions in Martini
- Register or obtain the DocuWare application credentials required for the deployment
- Prefer OAuth 2.0 where supported and store client credentials and tokens as Martini secrets
- Configure organization and tenant-specific values separately for each environment
- Use the least-privilege DocuWare user or application permissions required by the workflow
Objective
Select an event-driven, API-led, or scheduled entry point based on the DocuWare capability and the business latency requirement.
Instructions in Martini
- Use a Martini API or workflow trigger for upstream document filing and retrieval requests
- Use a DocuWare webhook notification only for confirmed supported events
- Use a scheduler for paginated archive synchronization or reconciliation
- Define acknowledgment behavior separately from longer-running document processing
Objective
Call the DocuWare Platform API to receive or retrieve the authoritative Document, File Cabinet, index, Dialog, or Workflow Task data needed for processing.
Instructions in Martini
- Construct the authenticated REST request with the required organization context
- Follow paginated search results rather than assuming one response contains all Documents
- Retrieve file content separately from metadata when the operation requires it
- Treat webhook payloads as notifications and retrieve the current resource when necessary
Objective
Use a Martini workflow to coordinate API calls, content handling, routing, enrichment, and downstream writes as one maintainable integration process.
Instructions in Martini
- Separate binary document handling from metadata and business-state processing
- Use reusable workflow logic for common DocuWare authentication, search, and error paths
- Apply controlled concurrency for high-volume downloads or uploads
- Persist checkpoints and correlation identifiers for long-running synchronization
Objective
Transform DocuWare metadata and file payloads into the canonical model required by the target application or map source data into DocuWare File Cabinet fields.
Instructions in Martini
- Map source identifiers to stable DocuWare Document Index Fields
- Validate field names, data types, required values, and allowed values for the target File Cabinet
- Preserve the DocuWare Document identifier after successful creation
- Use canonical models when the same document moves between multiple applications
Objective
Apply authorization, routing, duplicate-prevention, validation, retention, and content-handling rules before committing changes.
Instructions in Martini
- Check source-system identifiers or deterministic hashes before creating a Document
- Enforce document type, customer, invoice, contract, or workflow routing rules
- Reject invalid files and incomplete required index data before upload
- Prevent sensitive content and tokens from being written to operational logs
Common DocuWare data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Organizations | Represent the DocuWare tenant or organizational boundary containing users, File Cabinets, workflows, and configuration. | Identity services, administration systems, enterprise configuration stores | Martini keeps organization context in environment configuration and uses it when constructing authenticated API requests. |
| File Cabinets | Provide repositories for storing Documents and their index data. | Salesforce, Microsoft Dynamics 365, SAP, Microsoft 365, records repositories | Martini selects the File Cabinet through configuration or business rules, validates its required fields, and routes document operations to the appropriate resource. |
| Documents | Represent stored files together with metadata, index fields, sections, and document relationships. | ERP applications, CRM platforms, signing platforms, data warehouses, records systems | Martini separates binary content from metadata, maps fields, stores stable DocuWare identifiers, and applies idempotency and retry logic. |
| Document Index Fields | Classify, search, route, and retrieve Documents using business metadata such as customer, invoice, contract, or document type. | Salesforce, SAP, Microsoft Dynamics 365, DocuSign, reporting systems | Martini transforms source fields into File Cabinet-specific names, data types, and allowed values before storage or update. |
| Dialogs | Provide configured search, store, result, or task interactions with DocuWare Documents and processes. | Business applications, employee portals, customer portals | Martini invokes configured Dialog resources where appropriate and converts results into stable application-facing responses. |
| Workflow Tasks | Represent work items generated by DocuWare workflows and assigned to users or groups. | Workflow applications, notifications, task-management systems | Martini can retrieve related workflow resources after supported notifications, apply routing rules, and invoke downstream APIs. |
Authentication and security considerations
OAuth 2.0 and bearer tokens
Use OAuth 2.0 for new DocuWare integrations where supported. Martini can store client credentials, refresh tokens, access tokens, and organization configuration in environment-specific secrets and send bearer tokens with API requests.
Permissions and organization context
DocuWare user and application permissions control access to File Cabinets, Documents, Dialogs, searches, and workflow resources. Configure the least-privilege access required by each workflow and keep development, testing, and production credentials separate.
Document protection
- Do not write document content or access tokens to Martini logs.
- Protect inbound webhook and API endpoints with appropriate authentication and authorization.
- Consider retention, residency, audit, and deletion requirements for both DocuWare and Martini.
Operational considerations for DocuWare integrations
Pagination and throughput
Document searches can return multiple pages. Use stable identifiers, incremental criteria where available, bounded concurrency, and checkpoints rather than repeatedly scanning an entire File Cabinet.
Retries and idempotency
Use bounded exponential-backoff retries for transient failures and distinguish them from permission, validation, conflict, and authentication errors. Make webhook handlers and scheduled jobs safe to run more than once.
Content and schema validation
Validate file type, size, filename, required index values, and File Cabinet data types before storage. File Cabinet fields, Dialog definitions, and workflow configurations can change, so externalize identifiers and monitor for unexpected schema changes.
Testing and monitoring
Test representative metadata, binary content, pagination, duplicate delivery, permission failures, and malformed files in a non-production environment. Monitor workflow outcomes without exposing sensitive document data.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini provides a durable workflow layer for DocuWare API calls, webhook handling, scheduled synchronization, downstream writes, validation, and business rules. This makes multi-step document processing easier to maintain than separate scripts for each use case.
Reusable integration assets
Common authentication, search, pagination, mapping, content handling, and error paths can be reused across DocuWare workflows and applications. Martini can also expose controlled APIs so consuming systems do not need direct access to DocuWare.
Operational control
- Centralize environment-specific secrets and organization configuration.
- Apply consistent retry, checkpoint, idempotency, and monitoring practices.
- Separate binary content from metadata and protect sensitive document information.
Frequently asked questions
DocuWare can be integrated primarily through its Platform REST API, which supports Organizations, File Cabinets, Documents, Document Index Fields, Dialogs, and workflow-related resources. Integrations can store and retrieve documents, search and update metadata, process file content, and use selected webhook-style notifications. OAuth 2.0 is preferred for new integrations where supported, while scheduled paginated synchronization can cover scenarios where event coverage is limited.
Yes. Martini can consume the DocuWare Platform REST API, receive supported DocuWare webhook notifications through an exposed API or workflow trigger, transform document metadata and file content, and orchestrate downstream workflows. No native Martini DocuWare connector is documented in the supplied materials.
No. A dedicated DocuWare connector is not required. Martini can use DocuWare's confirmed native integration mechanisms, including the Platform REST API, selected webhook-style notifications, OAuth 2.0 authentication, and document file operations.
Lonti does not charge an additional per-connector or per-vendor fee to integrate DocuWare. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from DocuWare, cloud infrastructure, or other third-party systems depending on subscriptions, usage, and deployment model.
New projects should generally use the DocuWare Platform REST API with OAuth 2.0 where supported. Use document and file-content operations for filing or retrieval, selected webhook-style notifications for confirmed event scenarios, and scheduled paginated searches with checkpoints when event coverage is unavailable or incomplete. A current official GraphQL or recommended SOAP interface was not confirmed.
DocuWare webhook-style notifications can trigger Martini processing for selected events or resources. Coverage is not universal, so the required event must be confirmed for the relevant DocuWare deployment. Martini should validate the notification, acknowledge it promptly, and retrieve the authoritative resource before longer downstream processing.
Martini can search DocuWare through paginated REST API requests, retrieve Documents and file content, map Document Index Fields into a canonical model, and write the result to another application or repository. Scheduled workflows should use incremental criteria where available, durable checkpoints, stable identifiers, and idempotent processing to avoid duplicate exports.
Martini can classify authentication, permission, validation, conflict, throttling, and service failures, then apply bounded retries with backoff only to transient conditions. Duplicate prevention can use a source-system identifier, external correlation ID, document number, or deterministic content hash, with the DocuWare Document identifier persisted after successful storage.
Related Martini documentation
Workflows
Connect DocuWare with your enterprise systems
Use Martini to build secure, maintainable DocuWare integrations around REST APIs, document content, selected notifications, scheduled synchronization, and reusable workflows.