OpenText Digital Asset Management (ex-Media Management) API

Authentication

Required anti-CSRF header S1. Every request must carry one of the following headers, otherwise it is rejected with HTTP 400:

• X-Requested-By: <session id>
• otmmauthtoken: <message digest>
• Authorization: <access token>

Session login (Basic) S1

1. POST/otmmapi/v6/sessions with form fields username and password.
2. The response sets a JSESSIONID cookie and returns a session object whose message_digest is the user token.
3. Send either the cookie or the header otmmauthtoken: <digest> on later calls.
4. Log out with DELETE/v6/sessions. GET/DELETE/v6/users/me/sessions lists or kills all of the user's sessions.

Remote user header / SSO resolver S1

• Configure on the server ("Configuring Remote User Header" and "Configuring Single Sign-On Resolver" in the OTMM Integration Guide, Behind login), then call GET/v6/sessions to get a session.
• POST/v6/sessions/otdssessions (target_resource) returns an OTDS ticket for another resource.
• The Media Widget authenticates with an OTDS ticket in a configurable SSO header, or with an OTDS OAuth token S7.

OAuth 2.0 (OTDS) S1

1. Register an OAuth client in OpenText Directory Services (OTDS) to get a client ID and secret. The procedure is in the OTDS documentation and in "Using OAuth2.0 to Access OTMM REST APIs" (Integration Guide), both Behind login.
2. POST/otmmapi/v6/sessions/oauth2/token (form-encoded): client_id, client_secret, grant_type = client_credentials | password (+ username, password) | refresh_token (+ refresh_token). The spec describes it as "intended for server-to-server authentication" and equivalent to logging in.
3. POST/v6/sessions/oauth2/tokens/validate validates a token (since CE 23.2) S1 S5.
4. Unverified Header scheme contradiction. The spec says to send Authorization: Basic [access_token], and its sample token is an OTDS-issued JWT obtained with client_credentials S1. OpenText's own pyxecm client sends Authorization: Bearer <token> after a password grant S14. Which schemes a given server accepts is Unknown without testing.

Core resources

Paths are relative to https://{tenant}/otmmapi. Inventory parsed from the CE 23.2 spec S1.

Not exposed in the documented API (checked against the CE 23.2 spec S1): creating metadata models or fields, user/group provisioning, security-policy authoring, workflow (job definition) authoring, SSO configuration, and an analytics or reporting API.

Data model

S1 unless noted.

• Asset.
  • Identified by asset_id, a 40-character hex string in examples S14. Versions share an original_asset_id.
  • Key properties: name, mime_type, content_type / content_sub_type, metadata_model_id, metadata, security_policy_list, path_list (all folder paths), master_content_info, rendition_content, asset_state, content_state, locked, checked_out, deleted, expired, latest_version, delivery_service_url, streaming_url, progressive_download_url, deep_zoom_info, asset_color_infos, product_associations, review_info_collection.
• Metadata. Each asset follows a metadata model, a list of fields and field groups. A metadata field has an id (system id such as ARTESIA.FIELD.…), data_type, edit_type, domain_id (lookup domain), cascading_group_id, and required, multilingual, searchable, facetable and sortable flags. Values can be scalar, tabular or multilingual.
• Content. ContentInfo describes the master file and each rendition: id, mime_type, content_size, width/height, url (for example /otmmapi/v6/renditions/{rendition_id}), content_signed_url, content_checksum S1 S14.
• Containers. Folders (with folder types) and collections hold assets. Selection contexts (asset IDs, folder, search, collection) target bulk operations and can filter by permission (ASSETVIEW_PERM, EXPORT_PERM, METAEDIT_PERM…).
• Naming. JSON uses snake_case, and resources are wrapped (for example asset_resource.asset). Java client classes map camelCase to snake_case through EclipseLink MOXy providers shipped with the server.
• Heritage. Class names in the spec still read com.artesia.search.*, the SDK JAR is TEAMS-sdk.jar and the default search plugin is ARTESIA.PLUGIN.SEARCH.SOLR.V1. These names trace back to the Artesia TEAMS platform S1 S18.
• Errors. Failed calls return {"exception_body": {"http_response_code", "message" (localised), "debug_message", "failed_ids", "error_code"}}.

Search & querying

Uploads & binaries

Create assets with content S1

• POST/v6/assets as multipart/form-data (UTF-8 file names): asset_representation (JSON) and/or import_template_id, parent_folder_id, the file part(s), optional no_content=true for metadata-only assets, and optional review job/task IDs.
• The call creates a job and returns a job_handle.job_id. Poll GET/v6/jobs/{id} until it completes, or pass a callbackurl.
• Security: if only an asset representation is given, the user needs "Apply/Remove Security Policy" permission for every policy it assigns. Policies inherited from an import template do not require it.

Staged import S1

1. POST/v6/jobs/imports creates an import job.
2. POST/v6/renditions uploads the content against that job.
3. PUT/v6/jobs/imports/{import_job_id} registers the assets.

Related calls: PUT/v6/jobs/checkins/{import_job_id} adds a new version to existing assets; PUT/v6/jobs/attachcontents/{import_job_id} attaches content to metadata-only assets.

Large files. Transfer schemes (/v6/transferschemes) negotiate alternative transfer sessions S1. The OpenText Accelerated File Transfer add-on handles very large uploads and downloads S16. Size limits: Unknown.

Downloads S1

• GET/v6/assets/{id}/contents returns the original, or a rendition when rendition_type is set.
• GET/v6/renditions/{id} returns a rendition by ID. GET/v6/renditions/{id}/contentsignedurls returns a signed URL served directly by the storage provider.
• Export jobs (POST/v6/jobs/exports, then GET/v6/jobs/{id}/exports/contents) package assets, with transformers, for delivery.
• For channel delivery, Adaptive Media Delivery serves rendition URLs by profile, and the Media Widget returns AMD link URLs S16 S7.

Events & webhooks

• Job callbacks are the only push mechanism documented S1:
  • Add callbackurl=<url-encoded URL> to import/export (and other job) requests, with callbackmethod=GET (sends job ID and status as parameters) or callbackmethod=POST (adds asset IDs and error details).
  • Query parameters prefixed header_ are sent back as HTTP headers. This is the only built-in way to pass a shared secret.
  • Custom callback authentication: implement the Java interface com.opentext.job.notification.JobCallbackNotifier, register it as a system setting under [JOB\CONFIG], and add callbackauthscheme=CUSTOM&callbackclientId=<setting> to the callback URL.
  • Signing, retries and ordering: Not public.
• Subscriptions (assets, folders, collections) let users follow changes S1. How notifications are delivered (email or in-app) is Behind login.
• Integration Service (outbound publishing) S6:
  • A standalone microservice built on Apache Camel. Custom Java integrations implement com.opentext.is.service.interfaces.IntegrationService.publishContent(PublishJobRequest).
  • The service calls back OTMM with COMPLETED, FAILED or COMPLETED_WITH_ERRORS plus the object and audit URLs.
  • Integrations are packaged as JARs and registered through /v6/integrationservices. On managed deployments, the Service Delivery Manager must be involved.
• Media Widget audit events. IDs 8060 "Asset Placed" and 8061 "Asset Placement Removed" go to the OTMM audit trail. They must be added to the ASSET_EVENT_IDS_FOR_AUDIT setting S7.

Limits & quirks

• No published spec after CE 23.2. The developer portal's newest OTMM spec dates from 2023-07-31, while the product is at CE 26.2 S2 S17. Endpoints added after 23.2: Unknown.
• Mandatory CSRF header. Calls without X-Requested-By, otmmauthtoken or Authorization fail with HTTP 400, even when a valid JSESSIONID cookie is present S1.
• Basic vs Bearer in the OAuth header (see Authentication) Unverified S1 S14.
• Version-path drift in the docs. The CSRF sample targets /otmmapi/v2 while every resource is /v6 S1. Only v6 and the previous version are supported.
• Parameters as JSON strings. Search conditions, data-load requests and selection contexts are JSON objects serialized into query or form parameters, not request bodies, so URLs can get very long S1.
• Asynchronous writes. Asset creation, import, export, check-in and publish return job handles, so clients must poll jobs or use callbacks S1.
• Javadocs as contract. Fields, methods and classes missing from the Javadocs are internal and may change without notice S1.
• CORS. Browser calls (for example, an embedded Media Widget) need the origin in the CORS_ORIGIN_LIST system setting. OpenText advises against * S7.
• Licensing and access. In the G-Cloud offer, the API "is not designed for End Users" and is reached through a Professional Services engagement S33. Rate limits and quotas are Not public.
• Sample secrets in the spec. The published spec embeds a sample OTDS JWT, with an internal IP address as iss, in its prose S1. It is vendor sample data, kept verbatim in the archived copy on DAM Wiki (API spec downloads).

SDKs, tools & code samples

No official JavaScript/TypeScript, .NET or PHP SDK was found S1 S39.

Core DAM API

A separate product with a separate, much smaller API S8 S9 S10.

Changelog of the API