Tenovos Content Intelligence Platform (3.0)

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

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:

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
• update — modify document metadata fields; uses partial update (only supplied fields change)
• delete / undelete — soft-delete with restore; deleted documents remain queryable with a filter
• purge — permanently remove a document and all its edges
• reindex — trigger re-indexing of a document into OpenSearch; use after bulk imports or schema changes

Documents reference binary content managed by the Content Storage service and are typed using Document Types with optional schema enforcement via Document Schemas.

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:

Platform-provided default kinds:

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:

Available field types:

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:

Condition operators:

Condition sources — what the condition evaluates against:

Available actions:

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
• delete — permanently remove a rule

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:

Adapter management:

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:

• 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

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:

1. The recipient visits a share link and enters their email address
2. generate-otp sends a time-limited OTP to that address
3. 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
• update — modify share settings (expiry date, recipient list, permissions)
• retrieve / list — inspect share details and enumerate active shares in the organization
• update-access — adjust what a specific recipient can do (view-only, download, etc.)
• revoke — immediately invalidate a share; recipients lose access on their next request

External recipients authenticate into a share using Share Authentication and then access content via Shared Content.

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:

Job 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