.png)
OpenText Content Management Integration Guide
Connect OpenText Content Management with enterprise applications through REST APIs, document transfers, metadata synchronization, workflows, and controlled API orchestration.
OpenText Content Management integration options at a glance
OpenText Content Management primarily integrates through REST APIs for authentication, nodes, documents, metadata, search, users, groups, permissions, versions, and selected workflow operations. Document upload and download are core capabilities and may require multipart requests, version handling, reservations, and permission checks. Legacy SOAP or web-service interfaces may remain necessary for specific deployments or functions. Universal webhooks and a single bulk API for every object type were not confirmed, so scheduled Martini workflows can query changed content, paginate through collections, and maintain durable checkpoints. Martini can securely manage Content Server tickets, map categories and attributes, orchestrate workflows, expose controlled APIs, and handle retries and operational errors.
| Integration point | Supported by OpenText Content Management? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Authenticate, create folders and documents, upload and download content, search, manage metadata, retrieve users and groups, and work with versions and selected workflow functions. | Martini can consume OpenText REST endpoints, generate reusable API assets from definitions where available, map responses, and orchestrate multi-step workflows. |
| SOAP APIs | Limited | Support existing Content Server web-service integrations or functions that are unavailable in a particular REST API release. | Martini can consume SOAP services and transform XML responses, while REST should generally be evaluated first for new integrations. |
| Webhooks / outbound callbacks | Not confirmed | OpenText modules, workflows, WebReports, or notification features may provide event-driven behavior, but universal REST webhooks were not confirmed. | Martini can receive a supported callback if the deployment exposes one; otherwise it can use scheduled workflows and incremental queries. |
| File / attachment APIs | Yes | Upload and download document content, preserve filenames and MIME types, and manage content associated with nodes and versions. | Martini can handle multipart requests, stage or transform files, map metadata, and apply size, permission, reservation, and versioning rules. |
| Bulk / async / batch APIs | Limited | Large synchronizations and migrations may use pagination, incremental queries, exports, migration tools, or batch-oriented workflows. | Martini can paginate requests, maintain checkpoints, process batches, throttle concurrency, and route failed items for retry. |
| Authentication | Yes | The common REST pattern authenticates with Content Server and receives an OTCSTicket used in subsequent requests. | Martini can store credentials and tickets as environment-specific secrets, refresh expired tickets, and separate authentication failures from business errors. |
| Database access | Not confirmed | Direct SQL access is not the standard application-integration path; supported APIs, reports, exports, and product interfaces are preferred. | Martini can connect to databases when separately supported, but should not depend on internal OpenText database tables for content integration. |
| SDKs and client libraries | Limited | Existing implementations may use Java, .NET, SOAP clients, WebReports, or product extensions; availability varies by release. | Martini can use documented HTTP and SOAP interfaces directly and add custom JVM-compatible logic where justified. |
How OpenText Content Management exposes data and business events
OpenText REST APIs
OpenText Content Management provides REST resources for authentication, nodes, documents, metadata, search, users, groups, versions, permissions, and selected workflow operations. Exact resources and paths depend on the Content Server release, modules, and deployment configuration.
Martini implementation pattern
Martini implementation pattern: Martini authenticates to obtain an OTCSTicket, invokes the required REST resources, validates responses, maps OpenText objects into canonical models, and orchestrates writes to downstream systems. It can expose a controlled Martini API when consumers should not access Content Server directly.
Implementation sequence
OpenText document and file APIs
Document content is central to OpenText Content Management. REST interfaces can upload and download files associated with nodes, subject to permissions, multipart requirements, version behavior, reservations, and large-file constraints.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves a document, stages or streams it as appropriate, maps filename, MIME type, node location, categories, and attributes, then performs the upload or download with durable status and error handling.
Implementation sequence
OpenText SOAP services
OpenText Content Server has historically exposed SOAP-based web services that may remain relevant for existing implementations or functions unavailable in a target REST release. SOAP is a compatibility option rather than the preferred default for new integrations.
Martini implementation pattern
Martini implementation pattern: Martini consumes the documented SOAP service, transforms XML into a canonical model, applies workflow and validation rules, and sends the result to REST APIs or downstream systems when the process spans multiple interfaces.
Implementation sequence
Scheduled incremental synchronization
A universal webhook model for all Content Management objects was not confirmed. Scheduled workflows can query supported modification information, paginate through collections, and process exports when event coverage is unavailable.
Martini implementation pattern
Martini implementation pattern: Martini runs on a schedule, loads a durable checkpoint, queries changed nodes or metadata with an overlap window, processes pages in bounded batches, and commits the checkpoint only after successful handling.
Implementation sequence
OpenText workflow coordination
OpenText workflows can include definitions, assignments, tasks, and status information where the relevant module and endpoint are enabled. Exact operations must be verified for the installed deployment.
Martini implementation pattern
Martini implementation pattern: Martini coordinates application events with supported OpenText workflow operations, synchronizes document metadata and status, and routes unsupported module-specific actions through a deployment-specific review.
Implementation sequence
Common OpenText Content Management integration patterns
Pattern 1: Synchronize documents and metadata with a business application
When to use this pattern
Use this pattern when an application needs selected OpenText documents, metadata, and version changes on a recurring basis. It is appropriate when universal document webhooks are unavailable or event coverage must be verified per deployment.
Integration direction
Example Mapping
| OpenText Content Management Field | Canonical Field | Target Field |
|---|---|---|
| Node ID | content.externalId | OpenText Node Reference |
| Name | content.fileName | File Name |
| Modify Date | content.modifiedAt | Last Modified |
| Category Attributes | content.metadata | Document Metadata |
Martini implementation pattern
A scheduled Martini workflow loads a checkpoint, queries changed nodes with pagination, retrieves metadata and content, compares node/version identifiers, maps fields, and updates the target application. It uses overlap windows, durable idempotency keys, bounded concurrency, and retry or dead-letter handling for transient and functional failures.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- error handling
Pattern 2: Archive application-generated documents in OpenText
When to use this pattern
Use this pattern when SAP, Salesforce, Workday, or another application generates invoices, contracts, employee documents, or correspondence that must be stored in OpenText with governed metadata.
Integration direction
Example Mapping
| OpenText Content Management Field | Canonical Field | Target Field |
|---|---|---|
| Business Document ID | document.businessKey | Category Attribute: Business ID |
| Document Type | document.type | Category Attribute: Document Type |
| File Content | document.binary | Document Content |
| Company Code | organization.code | OpenText Category Attribute |
Martini implementation pattern
Martini receives an API request or supported event, validates the document and required attributes, resolves the destination folder, maps metadata into OpenText categories, and uploads the file. It searches or checks a durable source-to-node mapping before creation to prevent duplicates and returns the OpenText reference to the source application.
Martini capabilities used
- API endpoints
- workflow orchestration
- multipart file handling
- data transformation
- validation
- idempotency
- retry handling
Pattern 3: Retrieve OpenText content through a controlled API
When to use this pattern
Use this pattern when downstream applications need document content but should not receive direct Content Server credentials or broad repository access.
Integration direction
Example Mapping
| OpenText Content Management Field | Canonical Field | Target Field |
|---|---|---|
| Node ID | content.reference | Request nodeId |
| Version Number | content.version | Requested Version |
| Document Content | content.binary | Mediated Response Body |
| MIME Type | content.mimeType | Response Content Type |
Martini implementation pattern
A Martini API validates the caller and request, retrieves the node metadata and permitted version from OpenText, applies business rules, and returns a controlled response or mediated download result. Authorization failures, missing nodes, and timeouts are classified separately from retryable server errors.
Martini capabilities used
- API exposure
- authentication and authorization
- API consumption
- business rules
- file handling
- error handling
Pattern 4: Coordinate document workflows with business systems
When to use this pattern
Use this pattern when a business process creates or updates OpenText content and must synchronize workflow status with SAP, Salesforce, ServiceNow, or Workday. Availability depends on the installed OpenText workflow module and REST resources.
Integration direction
Example Mapping
| OpenText Content Management Field | Canonical Field | Target Field |
|---|---|---|
| Case Number | process.businessKey | OpenText Workflow Reference |
| Attachment Node ID | content.externalId | Document Reference |
| Workflow Status | process.status | Case or Process Status |
| Assigned User or Group | process.assignee | Task Assignment |
Martini implementation pattern
Martini receives the business event, creates or updates the document, invokes supported workflow operations, and synchronizes status back to the originating application. It persists workflow identifiers, avoids repeating actions after timeouts, and routes module-specific or unsupported operations for review.
Martini capabilities used
- event or API-triggered workflows
- workflow orchestration
- data mapping
- business rules
- idempotency
- monitoring and error handling
Applications commonly integrated with OpenText Content Management
OpenText Content Management can be integrated with enterprise applications that create, reference, archive, or govern business documents. Exact capabilities depend on the OpenText edition, installed modules, deployment configuration, and adjacent application APIs.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Archive invoices, purchase orders, vendor documents, engineering records, and business workspace content while synchronizing document references and status with SAP processes. | SAP S/4HANA → Martini → OpenText Content Management | Martini consumes SAP and OpenText APIs, maps SAP business keys to OpenText nodes and metadata, uploads or retrieves documents, and persists node and version mappings with retry handling. |
| Microsoft SharePoint | Coordinate collaboration content with governed OpenText repositories or migrate selected documents and metadata between platforms. | Microsoft SharePoint → Martini → OpenText Content Management | A Martini workflow reads selected SharePoint files and metadata, validates OpenText categories and attributes, creates folders or nodes, uploads content, and records the resulting OpenText reference. |
| Salesforce | Archive contracts, customer correspondence, case documents, and account-related files in OpenText while retaining references in Salesforce. | Salesforce → Martini → OpenText Content Management | Martini receives Salesforce API data, applies document and account business rules, creates or updates OpenText content, and returns node references and status to Salesforce. |
| ServiceNow | Store case attachments and supporting documents in a governed content repository while synchronizing links and workflow status with ServiceNow. | ServiceNow → Martini → OpenText Content Management | Martini consumes ServiceNow records and attachments, maps case identifiers to OpenText folders and metadata, uploads content, and writes the resulting node link or status back to ServiceNow. |
| Workday | Archive employee, payroll, recruiting, and HR documents with controlled metadata and return document references or process status to Workday. | Workday → Martini → OpenText Content Management | Martini validates Workday document payloads, transforms employee and document metadata into OpenText attributes, uploads files, and stores durable source-to-node mappings. |
| SAP SuccessFactors | Preserve employee-related documents and synchronize personnel or process metadata with OpenText repositories. | SAP SuccessFactors → Martini → OpenText Content Management | A scheduled or API-triggered workflow retrieves SuccessFactors documents, validates required OpenText categories, uploads content, and reports references or failures to the source system. |
| Oracle Fusion Cloud Applications | Archive finance, procurement, supplier, and customer documents associated with Oracle transactions. | Oracle Fusion Cloud Applications → Martini → OpenText Content Management | Martini retrieves Oracle document payloads, maps transaction identifiers and metadata, creates or updates OpenText nodes, and handles duplicate detection and transient failures. |
| Jira | Link project, change, or issue-related documents to governed OpenText repositories while keeping references visible in Jira. | Jira → Martini → OpenText Content Management | Martini reads selected Jira attachments, applies filtering and metadata rules, uploads approved content to OpenText, and posts the node reference and processing status to Jira. |
How to build a OpenText Content Management integration in Martini
Objective
Establish the OpenText base URL, API path, service account, and authentication behavior for the specific deployment.
Instructions in Martini
- Configure the Content Server endpoint for each environment
- Authenticate and obtain an OTCSTicket where required
- Store credentials, tickets, and URLs in Martini secrets or environment configuration
- Confirm permissions for the required nodes, documents, metadata, and workflow operations
Objective
Select a real-time, scheduled, or API-led entry point based on verified OpenText event coverage.
Instructions in Martini
- Use a supported callback only when the deployment exposes one
- Use a scheduler for incremental synchronization when universal webhooks are unavailable
- Expose a Martini API when another application should initiate content processing
- Define the checkpoint and replay strategy before processing changes
Objective
Retrieve OpenText objects and document content using supported REST resources or SOAP services where legacy compatibility is required.
Instructions in Martini
- Invoke the required REST resource or confirmed SOAP operation
- Use pagination for collection responses
- Retrieve metadata and content separately when appropriate
- Preserve node IDs, versions, filenames, and MIME types
Objective
Coordinate authentication, retrieval, validation, transformation, target writes, and response handling in a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, content retrieval, mapping, and target operations into reusable stages
- Apply bounded concurrency for bulk processing
- Persist source-to-node mappings and checkpoints
- Keep vendor-specific endpoint logic separate from canonical business rules
Objective
Convert OpenText nodes, categories, attributes, users, groups, and versions into the target system model.
Instructions in Martini
- Validate required categories and controlled attribute values
- Map multi-value, date, user, and security-related fields deliberately
- Apply filename, MIME type, size, and version rules
- Use a mapping version when OpenText category structures change
Objective
Enforce permissions, duplicate prevention, routing, retention-related decisions, and workflow conditions before writes.
Instructions in Martini
- Use node and version or source document identifiers as idempotency keys
- Check whether content already exists before creating a new node
- Route permission, validation, and missing-node conditions without blind retries
- Avoid logging credentials, tickets, document contents, or sensitive metadata
Common OpenText Content Management data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Nodes | Represent folders, documents, compound documents, shortcuts, URLs, and other content items. | SAP S/4HANA, Salesforce, SharePoint, ServiceNow, Workday | Martini maps node IDs, names, paths, types, and parent relationships, then persists stable references for idempotent synchronization. |
| Documents and document versions | Store binary content, metadata, version history, reservations, and renditions where enabled. | SAP S/4HANA, Salesforce, Workday, SharePoint, Oracle Fusion Cloud Applications | Martini manages multipart upload and download, preserves filenames and MIME types, compares versions or hashes, and applies content-specific retry rules. |
| Users | Represent Content Server accounts and profile information used for ownership, authorization, and workflow assignments. | Identity platforms, Workday, SAP SuccessFactors, ServiceNow | Martini retrieves and maps user identifiers and attributes while respecting deployment-specific permissions and identity configuration. |
| Groups | Support security, organizational membership, access control, and workflow routing. | Identity platforms, ServiceNow, Workday, SAP SuccessFactors | Martini synchronizes selected group data, applies filtering and mapping rules, and avoids assuming that all permissions are exposed through the same resource set. |
| Categories and attributes | Define metadata structures and values assigned to content. | SAP S/4HANA, Salesforce, SharePoint, Oracle Fusion Cloud Applications | Martini validates required attributes, maps controlled and multi-value fields, and versions mappings when category definitions change. |
| Workflows | Represent workflow definitions, assignments, tasks, and workflow status information. | SAP S/4HANA, Salesforce, ServiceNow, Workday | Martini can start or monitor supported workflow operations, synchronize status, and route unavailable module-specific operations for deployment review. |
Authentication and security considerations
Authentication and security
OpenText Content Management REST integrations commonly authenticate with Content Server credentials and receive an OTCSTicket that is supplied in subsequent requests. SSO, reverse-proxy authentication, and identity-provider behavior depend on the deployment.
- Store credentials, tickets, client secrets, and environment URLs in Martini secrets or secure configuration.
- Use a service account with only the permissions required for the integration.
- Test folder inheritance, explicit permissions, group membership, restricted documents, and workflow access.
- Do not assume OAuth 2.0, API keys, or JWT authentication are universally available for every Content Management REST installation.
- Do not log credentials, tickets, document contents, or sensitive metadata.
Operational considerations for OpenText Content Management integrations
Operational controls
OpenText API behavior varies by release, modules, licensing, reverse proxy, and deployment configuration. Confirm the base URL, API version, available resources, category definitions, and permission model in each environment.
- Use pagination and durable checkpoints for incremental synchronization.
- Use node ID plus version, source document ID, or another stable key for idempotency.
- Bound concurrency and apply backoff for transient failures; a universal rate limit was not confirmed.
- Handle multipart uploads, large files, reservations, check-in behavior, filenames, MIME types, and renditions deliberately.
- Classify authentication, permission, validation, missing-node, gateway, timeout, and temporary server failures separately.
- Test authentication, upload, metadata updates, search, version handling, and upgrade behavior with contract tests.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable integration orchestration
Point-to-point scripts often combine authentication, pagination, file handling, mapping, retries, and business rules in code that is difficult to reuse and operate. Martini provides a workflow and API layer for coordinating these concerns around OpenText Content Management.
- Centralize REST and SOAP interaction patterns while keeping vendor-specific logic separate from canonical mappings.
- Reuse authentication, validation, transformation, checkpoint, and error-handling logic across integrations.
- Expose controlled APIs without giving every downstream application direct Content Server access.
- Support scheduled, API-led, batch, and deployment-specific event-driven processing.
- Improve operational visibility through structured errors, workflow logs, monitoring, and controlled retries.
Frequently asked questions
OpenText Content Management can be integrated primarily through REST APIs for authentication, nodes, documents, metadata, search, users, groups, versions, permissions, and selected workflow operations. Document upload and download are central use cases. Existing deployments may also expose SOAP services, while scheduled synchronization may be needed when universal webhook coverage is unavailable.
Yes. Martini can consume the OpenText Content Management REST API, authenticate using an OTCSTicket where applicable, upload and download documents, map metadata and categories, coordinate workflows, and expose controlled APIs for downstream consumers. Martini can also consume SOAP services when a deployment requires them.
No. A dedicated OpenText Content Management connector is not required. Martini can use OpenText's confirmed REST APIs, document and file operations, authentication mechanisms, scheduled workflows, and SOAP services where required.
Lonti does not charge an additional per-connector or per-vendor fee to integrate OpenText Content Management. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from OpenText, cloud infrastructure, identity providers, storage, or other third-party systems.
The documented OpenText REST API should generally be the first choice for new integrations. Use its supported resources for authentication, nodes, documents, metadata, search, users, groups, and versions. SOAP is a legacy or compatibility option when the required operation is unavailable through the target REST release. Direct database access is not the recommended path.
A universal REST webhook facility covering every Content Management object and event was not confirmed. Specific modules, workflows, WebReports, or notification features may provide event-driven behavior, but coverage must be verified for the deployment. Martini can use a supported callback or implement scheduled incremental queries when callbacks are unavailable.
Martini can run scheduled or API-triggered workflows that retrieve OpenText nodes, metadata, content, and versions, then map them to a canonical or target model. Checkpoints, pagination, overlap windows, node/version identifiers, and source-to-node mappings help support incremental processing and duplicate prevention.
Martini can classify expired tickets, permission failures, missing nodes, validation errors, file-size issues, gateway failures, timeouts, and temporary server errors separately. Retryable failures can use bounded retries and backoff, while node/version or source document identifiers provide idempotency controls to prevent duplicate creation.
Related Martini documentation
APIs
Workflows
Connect OpenText Content Management with Martini
Use Martini to build secure, maintainable OpenText Content Management integrations for document exchange, metadata synchronization, workflow coordination, and controlled API access.