Secure, scalable REST APIs for the Tenovos Content Intelligence Platform — enabling content discovery, metadata management, AI enrichment, governance, and distribution across enterprise systems.
Documents are the primary data model in the Content Intelligence Platform. Each document is a JSON object that holds metadata as flexible name/value pairs — there is no fixed schema enforced at the storage layer, which allows content from diverse external systems (DAMs, cloud storage, SharePoint, Box, etc.) to be ingested without transformation.
Documents exist within a graph-like structure where nodes (individual documents) and edges (links between documents) form a highly relational content model. For example, a media document can be linked to a campaign document, enabling hierarchical queries and relationship traversal across the content graph.
Document traits define behavioral capabilities of a document type:
Trait
Description
SUMMARY
Document has a displayable summary representation
CHILDREN
Document can contain child documents
TILE
Document can be displayed as a tile/card
CONTENT
Document is linked to binary content (files)
PREVIEW
Document can generate a visual preview
INSIGHTS
Document tracks engagement analytics
TIMELINE
Document has a temporal lifecycle (start/end dates)
VERSION
Document supports versioning
SOURCE
Document tracks its originating content channel
Endpoint reference:
create — create one or more documents of a given kind, with optional external ID for deduplication
retrieve — fetch a document by ID with full metadata and linked content references
list — paginated listing of documents, filtered by kind, status, or metadata values
query — full-text and field-level search across the document graph
query-within — scoped search within a specific document hierarchy (e.g., within a brand or campaign)
link / unlink — create or remove typed edges between documents (e.g., link media to a campaign)
retrieve-links — traverse outbound edges from a document to its related documents
Creates one or more documents of a given kind, returning the IDs of newly created documents and any pre-existing duplicates.
Request: documents - List of documents to create. Each entry includes: kind - The Kind name this document belongs to. doc - The document body as an arbitrary JSON value. externalId - Optional identifier from an external system for deduplication and cross-reference.
Response: ids - IDs of the newly created documents. existingIds - IDs of pre-existing documents that matched by externalId (not re-created).
Security
bearerAuth
Bodyapplication/json
documentsArray of objects(tenovos_document_Document_Create)
Retrieves one or more documents by internal ID or external ID, with optional field projection and soft-delete inclusion.
Request: ids - List of internal document IDs to retrieve. externalIds - List of external IDs to retrieve documents by. fetches - Optional field projection expression limiting which document fields are returned. includeDeleted - When true, includes soft-deleted documents in the results.
Response: documents - List of Document objects (id, kind, doc body, timestamps).
Lists documents filtered by one or more kind names, with optional field projection and cursor-based pagination.
Request: kinds - List of Kind names to filter by. fetches - Optional field projection expression limiting which document fields are returned. includeDeleted - When true, includes soft-deleted documents in the results. pagination - Optional Pagination cursor and page size.
Response: documents - List of Document objects matching the filter. pageCursor - Opaque cursor for the next page. Absent when there are no further results.
Creates directional links from a source document to one or more destination documents at a specified property path.
Request: sourceId - ID of the document to link from. destIds - List of destination document IDs to link to. propertyPath - The field path on the source document that represents this relationship. destProperties - Optional per-destination properties. Each entry specifies destId and an optional weight used for ordering or scoring the relationship.
Response: destIds - IDs of the destination documents that were successfully linked.
Security
bearerAuth
Bodyapplication/json
sourceIdstring
Rule data fields
destIdsArray of strings
propertyPathstring
Rule data fields
destPropertiesArray of objects(tenovos_document_Document_DestProperties)
Removes links from a source document to one or more destination documents at a specified property path.
Request: sourceId - ID of the document to remove links from. destIds - List of destination document IDs to unlink. propertyPath - The field path on the source document where the links reside.
Response: destIds - IDs of the destination documents that were successfully unlinked.
Retrieves all outbound links for one or more source documents, returning destination IDs and property paths.
Request: sourceIds - List of source document IDs whose links to retrieve.
Response: docLinks - List of Links objects, one per source document. Each contains the sourceId and a list of Link entries (destId and propertyPath) representing all outbound relationships.
Executes a structured query against all documents in the organization, returning matching results with full control over which fields and traits are returned, how results are filtered, and how pages are navigated.
Query Language
Queries are expressed as a single string using a structured query language with up to four clauses:
The cursor value is the opaque pageCursor string returned in the previous response.
from() — Document Kind Selection
Specifies one or more document kinds to query. Kind names must be lowercase letters and underscores only (3–62 characters).
from(brand)from(asset, brand, region)
Default platform kinds: media, brand, campaign, category, toolkit, section, block. Custom kinds defined in your organization are also supported.
match() — Full-Text Search
Performs a full-text keyword search across indexed document content. Keywords are provided as a single-quoted string. Results are ranked by relevance when orderBy is not specified.
match('acme global')match('Q4 campaign hero')
filter() — Field-Level Conditions
Applies field-level conditions to narrow results. Expressions can be simple or compound.
Strings in filter conditions must be single-quoted. Supported escape sequences: \\, \', \n, \r, \t.
Property Paths
Property paths reference fields within a document and always begin with /. Nested fields are separated by /.
Path
Description
/
The root document
/name
Top-level field
/metadata/createdBy
Nested field
/tags
Array field
/$$id
Reserved system field (prefixed with $$)
Range selectors on link properties — link fields (relationships to other documents) support a range selector [start..end] to limit which linked items are returned. Both bounds are zero-based; start is inclusive, end is exclusive.
Syntax
Description
/items[0..5]
First 5 linked items
/items[3..]
All linked items from index 3 onward
/items[..10]
First 10 linked items
/items[2..8]
Items at indices 2 through 7
Ranges can appear at multiple levels of a path:
fetch(/sections[0..3]/media[..10]) from(toolkit)
Traits
Traits define a standard contract for a set of fields a document kind can return. They are referenced in fetch() using the $ prefix.
Trait
Parameters
Returned Fields
$summary
—
name, description
$tile
—
fgColor, bgColor, iconUrl
$children
limit (optional)
items (array), depth
$content
—
id, mimeType, contentType, size, filename, description, caption; plus type-specific: image (width, height), video (width, height, durationMs), document (width, height, pages)
$preview
w, h, representationType
id, url
$insights
—
Array of insight metrics (single value or timeseries)
$timeline
—
from, to (timestamps)
$version
—
number, isLatest
Sub-traits apply a secondary trait to each item returned by the parent:
fetch($children$summary) # fetch children, return $summary for eachfetch($children$summary(limit=5)) # limit to 5 children
Complete Examples
# Fetch all fields from a single kindfetch(/) from(brand)# Fetch specific fieldsfetch(/name, /status, /region) from(asset)# Fetch a traitfetch($summary) from(brand)# Fetch multiple traits and fieldsfetch($summary, $tile, /metadata) from(brand)# Fetch a trait at a nested pathfetch(/heroImage/$preview(w=800, h=600)) from(campaign)# Full-text searchfetch($summary) from(asset) match('product launch 2024')# Filter by a field valuefetch(/) from(asset) filter(/status == 'approved')# Filter with ANDfetch($summary) from(asset) filter(/status == 'active' && /owner != null)# Filter with OR and groupingfetch($summary) from(asset)filter((/status == 'active' || /status == 'pending') && /region != null)# Contains / not-containsfetch(/) from(asset) filter(/tags ... 'featured')fetch(/) from(brand) filter(/name !.. 'draft')# Query multiple kindsfetch($summary) from(brand, region, asset) filter(/status == 'active')# Order and paginatefetch($summary).orderBy(/name, asc).limit(20) from(brand)# Continue from a cursorfetch($summary).orderBy(/name, asc).limit(20, nextPageCursorToken) from(brand)# Fetch linked items with a rangefetch(/items[0..5]) from(category)# Nested rangesfetch(/sections[0..3]/media[..10]) from(toolkit)# Limit children with trait attributefetch($children(limit=5)) from(category)# Combined: search, filter, order, paginatefetch($summary, $preview(w=400, h=300)).orderBy(/name, asc).limit(10, abc123)from(asset)match('campaign hero')filter(/status == 'active' && /region != null)
Request Parameters
Parameter
Type
Required
Description
query
string
Yes
The query expression string
verbose
boolean
No
When true, includes per-phase execution timing in the response (info field)
Response
Field
Description
documents
List of matching document objects
pageCursor
Opaque token to pass to the next request to retrieve the next page; absent when no further pages exist
info
Query timing breakdown by phase (match, filter, projection) — only present when verbose: true
Performs a keyword search within the content of a specific document, returning a relevance-scored series of matching positions. This is distinct from the query endpoint, which searches across documents — query-within searches inside a single document's indexed content.
This is most useful for long-form content where you want to locate specific passages, pages, or moments, for example:
Finding the page in a PDF where a keyword appears
Locating the timestamp in a video where a term is spoken
Searching within a large document's indexed text body
Request Parameters
Parameter
Type
Required
Description
id
string
Yes
The ID of the document to search within
keywords
string
Yes
The keyword or phrase to search for within the document's content
minScore
number
No
Minimum relevance score threshold (0.0–1.0). Points scoring below this value are excluded from the response. Use to filter out low-confidence matches.
Response
Field
Description
series
A scored series of matching positions within the document
Each point in the series contains:
Field
Type
Description
score
number
Relevance score for this match (higher is more relevant)
ref
integer or string
Position reference — an integer page index for paginated content (PDFs, slide decks), or a timecode string for time-based content (video, audio)
Example
To find all moments in a video where "product launch" is mentioned, with a minimum relevance score of 0.5:
Applies an ordered sequence of field-level patch operations to one or more existing documents. Patches are applied in the order supplied; if any patch in the sequence is invalid, the entire update for that document is rejected.
Request: updates - List of documents to update. Each entry includes: id - The document ID to target. Either id or externalId must be supplied. externalId - The external system ID to target (alternative to id, useful when the document was created with an externalId for cross-system referencing). patches - Ordered list of patch operations. Field paths use forward-slash notation matching the document's field structure (e.g. /name or /metadata/status). Each patch is one of: Add(path, value) — sets a field that does not yet exist. Remove(path) — removes the field at the given path. Replace(path, value) — overwrites an existing field's value.
Response: ids - IDs of the documents that were successfully updated.
Security
bearerAuth
Bodyapplication/json
updatesArray of strings or tenovos_document_Document_UpdateDocument_Patch (object)
Document Types (internally called kinds) define the categories of content that exist in your organization — controlling how documents are classified, displayed, and processed by downstream services. Every document must declare a kind at creation time.
Kinds have a KindType classification that describes their primary role:
KindType
Description
ASSET
Represents a binary file or media asset (images, video, documents)
REFERENCE
Represents a business entity that other documents relate to (brands, campaigns)
COLLECTION
Groups related documents together (categories, playlists)
LAYOUT
Structures content for presentation (toolkits, sections, blocks)
OTHER
Custom or unclassified kind
Platform-provided default kinds:
Kind
KindType
Description
media
ASSET
Represents assets that originate from external channels (images, video, files). Linked to binary content, brands, campaigns, and source channel.
brand
REFERENCE
Organizational brand entity. Links to a logo and splash image. Fields: name, description, fgColor, bgColor.
campaign
REFERENCE
Marketing campaign. Links to brands and splash images. Fields: title, description, brief, start, end.
Groups sections of content representing a brand identity. Links to sections and a parent brand.
section
LAYOUT
Page layout element holding multiple blocks. Links to a toolkit, parent section, and child blocks.
block
LAYOUT
Page element holding rich text and media. Links to media items.
Kinds are organized into groups for display in the platform UI (e.g., "Media Assets", "Creative Briefs"). Use list-default-groups to retrieve platform-defined groupings. Custom kinds can be created to extend this model for organization-specific content structures.
Kinds work in conjunction with Document Schemas, which define the metadata field structure and validation rules applied to documents of a given kind.
Schemas define the metadata field structure for a Document Type — specifying which fields should be present, their data types, display labels, and validation rules (required, allowed values, min/max constraints). The platform stores metadata as schemaless name/value pairs at the document layer, but schemas allow you to enforce structure when needed.
Schema types:
SchemaType
Description
ROOT
Top-level schema attached directly to a Document Kind
SUB
Nested schema for structured sub-objects within a document
TRAIT
Schema associated with a behavioral trait (e.g., SUMMARY, TIMELINE)
Available field types:
Field Type
Description
string
Plain text value
integer
Whole number
number
Floating point number
bool
Boolean true/false
date
ISO 8601 date or datetime
array
List of values — element type can be string, integer, number, bool, or date
object
Nested JSON object (references a SUB schema)
link
Edge to another document; has a cardinality (ONE_TO_ONE, ONE_TO_MANY, MANY_TO_ONE, MANY_TO_MANY)
ref
Read-only reference to a field on a linked document
computed
Derived field calculated from other field values
Schema operations:
create-schema — define a new schema and attach it to a kind
update-schema — revise field definitions; changes apply to subsequent document writes
retrieve-schema / list-schema — inspect field definitions for a given kind
delete-schema — remove a schema, returning the kind to free-form metadata mode
Document Rules are automated policies that govern how documents behave as they are created or updated in the platform. Each rule defines conditions (when to fire) and actions (what to do). Rules are evaluated asynchronously by the Action & Media Flows service whenever a matching document event occurs.
Condition matching:
Rules evaluate conditions against document fields. The matchType controls how multiple conditions combine:
Match Type
Behavior
MATCH_ALL
All conditions must be true (AND logic)
MATCH_ANY
At least one condition must be true (OR logic)
MATCH_NONE
No conditions may be true (NOT logic)
Condition operators:
Operator
Description
OP_EQ
Field equals the specified value
OP_NE
Field does not equal the specified value
OP_MATCHES
Field matches a regular expression
OP_NOT_MATCHES
Field does not match a regular expression
OP_IS_EMPTY
Field is absent or null
OP_IS_NOT_EMPTY
Field is present and non-null
Condition sources — what the condition evaluates against:
Source
Description
SOURCE_KIND
The document kind (type)
SOURCE_DOC_VALUE
The current value of a document field
SOURCE_PREV_DOC_VALUE
The previous value of a field (before the triggering update)
Available actions:
Action
Description
setProperty
Write a metadata field value on the document
setLink
Create a link edge between the document and another document
setPolicy
Apply an access policy grant (READ or MODIFY) to the document
Rule lifecycle:
create / update — define or revise rule conditions and actions
enable / disable — activate or pause a rule without deleting it
test — evaluate a rule against a sample document payload before enabling in production
The Content Storage service manages references to binary content (files) through a pluggable adapter model. Adapters represent different physical storage backends — for example, AWS S3 (full read/write), CDN origins (Bunny, Bria), or external DAM connectors. Callers never interact with storage directly; they work with pre-signed URLs that the service generates on demand, allowing content to be streamed directly from the storage provider without proxying through the platform.
The service supports multiple adapters per organization with a priority ordering, so that suitable storage defaults are chosen automatically without callers needing to specify where content lives. Different adapters can be configured for different storage classes (hot, warm, cold), affecting retrieval latency and cost.
Content lifecycle:
Endpoint
Description
register
Record that a piece of content exists at a known storage location (used during channel sync)
retrieve-upload-url
Get a pre-signed URL to upload a new file directly to the configured storage adapter
stage
Prepare content for CDN delivery by writing it to the CDN origin adapter
retrieve-url
Get a pre-signed download or streaming URL for a content item
These endpoints provide authorization primitives for verifying user permissions and bootstrapping new user access within the Content Intelligence Platform.
The platform uses a role-based access control (RBAC) model managed by the Authorization service. Roles carry named permissions, and users are assigned one or more roles either explicitly or via User Groups.
has-permission — check whether the calling user holds a specific named permission; use this as a guard in custom integrations before performing sensitive operations
assign-default-role — assign the platform default role to a user, typically called during user provisioning or invite acceptance flows
For fine-grained, resource-level access decisions (e.g., "can this user access this specific document?"), see Access Control. For managing the roles themselves, see Roles.
User Groups organize users into named collections for streamlined access control and administration. Instead of assigning roles and permissions user-by-user, you assign them to a group and manage membership centrally.
Groups support a full lifecycle:
Create / Update / Retrieve / List — manage group definitions
Add Member / Revoke Member — control who belongs to the group
Activate / Disable — enable or suspend a group without deleting it; disabled groups do not grant their members any access
Purge — permanently remove a group and its membership records
Groups integrate with the Roles and Access Control systems, and are a key building block for multi-tenant or brand-scoped permission models.
Roles are named collections of Permissions that define what actions a user can perform across the platform. The platform uses a hierarchical RBAC model where users are assigned roles (directly or via User Groups), and those roles carry the permissions that gate access to API operations and content resources.
Role operations:
Create / Update — define a role and specify which permissions it grants
Retrieve / List — inspect role definitions across the organization
Activate / Disable — toggle a role without deleting it; disabling a role immediately removes its permissions from all assigned users
Purge — permanently delete a role
Roles are evaluated alongside fine-grained resource policies managed by Access Control to produce the final authorization decision for any given user and resource combination.
Manage user accounts within an organization — from initial invitation through ongoing profile management and access lifecycle.
create-invite — send an email invitation to a new user; the invited user completes signup via the platform authentication flow (powered by Clerk)
retrieve / list-users — inspect user profiles and organization membership
update-user — modify user profile attributes
assign-user-role — directly assign a Role to a specific user
disable-user — suspend access without deleting the account
delete-user — remove a user from the organization
User identity and authentication (login, SSO, MFA) are handled externally by Clerk. These endpoints manage the platform-side user record, role assignments, and access state.
Permissions are the atomic units of access control — named capabilities that define what a user or role is allowed to do (e.g., document:create, content:delete, channel:manage). Permissions are grouped into Roles, which are then assigned to users or User Groups.
list-permissions — enumerate all permissions defined in the platform; use this to understand what capabilities are available when designing custom roles
create-permission — define a new named permission, typically used when extending the platform with custom action types or integration-specific access gates
Access Control provides fine-grained, resource-level authorization on top of the role-based model. Where Roles and Permissions define what a user can do in general, Access Control governs what a user can do to a specific resource (e.g., a particular document, channel, or brand).
Document-level access supports two grant types:
Grant
Description
READ
User can view and retrieve the resource
MODIFY
User can update or delete the resource
has-access — evaluate whether the calling user has access to a specific resource; the primary authorization check for content-level operations
retrieve-resource-groups — list the logical resource groups a user has access to, used for scoping queries and UI navigation
grant-access — explicitly grant a user or group access to a specific resource
revoke-access — remove a previously granted resource-level access
API Keys enable programmatic, non-interactive access to the platform — suitable for server-to-server integrations, CI/CD pipelines, and automated content workflows that cannot use user-delegated OAuth tokens.
Each API key is scoped to the organization of the user who creates it and carries that user's permissions. Keys should be stored securely and rotated regularly.
create-api-key — generate a new API key; the raw key value is only returned once at creation
list-api-keys — enumerate existing keys (key values are not re-exposed)
revoke-api-key — permanently invalidate a key; any integrations using it will lose access immediately
Channels are the integration layer for connecting to external content systems — cloud storage, DAM platforms, social media, enterprise file systems, and others. Each Channel is a configured, authenticated connection to one of these external sources that the platform monitors, indexes, and keeps in sync.
The Channel Manager authenticates against external systems, scans for new and modified content, manages webhook subscriptions for real-time change notifications, and makes raw content available for retrieval — without managing the binary files directly. Binary retrieval is handled via pre-signed URLs delegated to Content Storage.
Channel categories:
Category
Description
ORIGIN
External content source to pull from (Box, Google Drive, SharePoint, S3, DAMs, etc.)
OBSERVATION
External system to observe for engagement events (Instagram, Facebook, Website, etc.)
DELIVERY
Destination to push content to
Currently available channel types:
Origin (content pull):
Channel
Group
Auth
Box
Cloud File Storage
OAuth
Google Drive
Cloud File Storage
OAuth
AWS S3
Object Store
Service Credentials
Tenovos DAM
DAM
OAuth
Adobe AEM
DAM
Service Credentials
Sitecore
DAM
OAuth
Bynder
DAM
OAuth
Brand Folder
DAM
OAuth
Azure Blob
Object Store
OAuth
Google Cloud Storage
Object Store
OAuth
SharePoint
Cloud File Storage
OAuth
Observation (engagement events):
Channel
Group
Instagram
Social
Facebook
Social
Website
Content Management and Sites
Authentication methods:
Auth Type
Description
OAUTH
User-delegated OAuth 2.0 flow; use retrieve-oauth-url then update-auth
API_KEY
Static API key submitted during channel creation
BASIC_AUTH
Username and password credentials
SERVICE_CREDENTIALS
Service account JSON or IAM role credentials (used by Adobe AEM, AWS S3)
Channel status lifecycle:
Status
Description
DRAFT
Channel created but not yet authenticated
AUTHENTICATED
Credentials stored; not yet scanning
ENABLED
Actively scanning and webhook-registered
DISABLED
Paused; configuration and credentials retained
Channel lifecycle endpoints:
list-channel-types / retrieve-channel-types — discover available integrations and their configuration requirements
create-channel — configure a new connection (name, settings, auth)
update-channel — modify an existing channel's settings
disable-channel — pause sync without deleting configuration; webhooks are torn down
delete-channel / purge-channels — remove channel(s) and all associated webhooks and scan state
validate-channel-config — test credentials and connectivity before enabling; returns OK, AUTH_FAILURE, or CONFIG_FAILURE
Authentication flow endpoints:
retrieve-oauth-url — get the OAuth authorization URL to redirect a user through
update-auth — exchange an OAuth authorization code or service credentials for stored tokens
Content discovery endpoints:
retrieve-folders — browse the folder, site, or library tree of a connected source
get-config-description — fetch the dynamic field schema for configuring a channel type; field types are TREE, DROPDOWN, or TEXT
get-config-details — retrieve selectable items (sites, folders, document libraries) for a specific channel instance
scan-content — manually trigger or resume a paginated content scan
retrieve-content — generate pre-signed download URLs for specific content items from the source
retrieve-content-metadata — fetch metadata for a specific item directly from the external source
retrieve-content-data — stream raw file content from the external source
retrieve-channel-account — return the authenticated account info (user profile, tenant ID, etc.) for a connected channel
Sync and operations:
resolve-webhook-payload — parse an inbound push notification from an external system into a normalized platform event (used internally)
channel-stats — retrieve scan statistics and sync state (ACTIVE, INACTIVE, SYNCING, or ERROR) for a channel
Scan behavior: Enabled channels run on an automatic schedule. Initial scans perform a full content crawl; subsequent delta scans (default interval: 10 minutes) retrieve only changes since the last successful scan using source-native change detection (e.g., Graph delta queries for SharePoint, change tokens for Box). Failed scans retry up to 5 times with a 30-minute cooldown between attempts.
Workflows (internally "flows") are the orchestration mechanism for longer-running, multi-step content operations. Where individual API calls handle atomic short-lived operations, Workflows wire multiple service calls together into a composite action — for example: ingest content from a Channel → extract metadata → apply Document Rules → publish to a destination.
The platform's services are designed around short-lived RPC calls. Workflows bridge them into durable, sequenced processes managed by the Action & Media Flows service, with each step tracked as a Job.
Create / Update — define a workflow, its steps, and step configuration
Retrieve / List — inspect workflow definitions; list-default-groups returns platform-provided workflow templates as a starting point
Enable / Disable — activate or pause a workflow without deleting it
Purge — permanently remove a workflow definition
Running instances of a workflow are tracked as Jobs. Use the Jobs API to monitor progress, handle failures, and restart or cancel executions.
Actions are the individual, atomic operations that can be composed into Workflows. Each action represents a discrete capability of the platform — for example, "ingest document from channel", "run media transform", "apply metadata schema", "send notification", or "publish to destination".
These endpoints are read-only discovery endpoints:
list — enumerate all available actions in the platform; filter by category or type to find actions relevant to a specific workflow step
retrieve — fetch the full definition of a specific action, including its input parameters, output shape, and configuration requirements
Use the Actions API to programmatically build or validate workflow definitions without relying on hardcoded action identifiers.
Jobs represent individual executions of Workflow steps or standalone async operations (such as a media transform). The Job system provides visibility into the progress, status, and output of long-running background tasks managed by the Action & Media Flows service.
Each job moves through a lifecycle: queued → running → succeeded / failed. Jobs run in isolated per-organization priority queues, ensuring one organization's workload does not block another's.
list — query jobs by workflow, status, date range, or content reference
retrieve — fetch the full status, logs, and output of a specific job
restart — re-queue a failed job; useful for transient failures such as network timeouts or temporary service unavailability
cancel — terminate a running or queued job; the job will not be retried
Share Authentication handles identity verification for external recipients — people outside the organization who have received a share link but do not have a platform account.
The platform uses a one-time passcode (OTP) flow for external share access:
The recipient visits a share link and enters their email address
generate-otp sends a time-limited OTP to that address
The recipient submits the OTP via exchange-otp, which returns a short-lived access token scoped to the specific share
This token is then used to call the Shared Content endpoints. It grants access only to what was explicitly included in the share — no other platform data is accessible.
The Sharing API lets platform users distribute content to external recipients — people without a platform account — in a controlled, auditable way. Shares are scoped to specific documents or collections and can be time-limited, password-protected, or restricted to specific recipient email addresses.
create — create a new share, specifying documents, recipients, expiry, and access level
These endpoints are called by external share recipients after authenticating via Share Authentication. They provide a read-only, scoped view of the content included in a specific share — no other platform data is accessible.
retrieve-shared-documents — list the documents included in the share, with metadata
retrieve-content — get a pre-signed download URL for a specific shared content item
retrieve-branding-content — fetch branding assets (logo, colors, fonts) associated with the share, used to render the share portal with the sender's organization branding
The Media Processing API exposes the Transform service — a managed job queue for converting, resizing, transcoding, and analyzing media files. Each organization has its own isolated priority queue, ensuring processing workloads remain independent across tenants.
Workers execute in Docker containers on AWS Lambda (migrating to Spot Fargate) and support a wide range of operations:
submit — enqueue a new transform job, specifying the input content reference, operation type, and output parameters; returns a job ID for status tracking
status — poll the current state of a job (queued, running, completed, failed) and retrieve the output content location when complete
cancel — remove a queued job before execution begins; jobs already running cannot be cancelled mid-execution