API Keys

Document Management

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
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.

Operations

Document Types

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`.
`category`	`COLLECTION`	Dynamically generated content groupings. Supports subcategory hierarchies. Fields: `name`, `label`, `description`, `versionNumber`, `depth`, `isLatest`, `keywords`.
`toolkit`	`LAYOUT`	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.

Operations

Document Schemas

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

Operations

Document Rules

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

Operations

Content Storage

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
`retrieve-info`	Fetch content metadata: size, MIME type, checksums, dimensions (for images)
`list-info`	Batch retrieval of content metadata for multiple items
`update`	Update mutable content metadata (alt text, tags, etc.)
`delete / undelete`	Soft-delete a content record with restore capability
`purge`	Permanently remove the content record (does not delete the underlying file from storage)
`deregister`	Remove the content reference without affecting the underlying stored file

Adapter management:

Endpoint	Description
`create-adapter`	Configure a new storage backend for the organization
`update-adapter`	Modify adapter settings (credentials, priority, storage class)
`retrieve-adapter / list-adapters`	Inspect configured adapters
`delete-adapter / undelete-adapter / purge-adapter`	Manage adapter lifecycle

Operations

Authentication

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.

Operations

User Groups

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.

Operations

Roles

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.

Operations

Users

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.

Operations

Permissions

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

Operations

Access Control

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

Operations

API Keys

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

Operations

Create an API key

Request

Creates a new API key for programmatic access, assigning it a role that defines its permissions.

Request: name - Human-readable label for the API key. expiresAt - Optional expiry timestamp. If omitted the key does not expire. roleId - Role to assign to the API key's associated service account, determining what operations the key is authorized to perform.

Response: id - Assigned API key ID. name - Key display name. keyHint - Last 4 characters of the key, for identification purposes. expiresAt - Expiry timestamp if one was set. key - The full plaintext API key. This is the only time the full key is returned; it is stored hashed and cannot be retrieved again.

Security

bearerAuth

Bodyapplication/json

namestring

Rule data fields

expiresAtobject(google_protobuf_Timestamp)

roleIdstring

Rule data fields

curl -i -X POST \
  https://api.tenovos.net/api/v1/api-key/create-api-key \
  -H 'Authorization: Bearer <YOUR_JWT_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "CI Pipeline Integration",
    "expiresAt": "2026-12-31T23:59:59.000Z"
  }'

Responses

OK

Bodyapplication/json

idstring

Rule data fields

namestring

Rule data fields

keyHintstring

Rule data fields

expiresAtobject(google_protobuf_Timestamp)

keystring

Rule data fields

Response

application/json

{
  "id": "string",
  "name": "string",
  "keyHint": "string",
  "expiresAt": {
    "seconds": 0,
    "nanos": 0
  },
  "key": "string"
}

Search API keys

Request

Lists API keys in the organization with optional filtering for revoked or expired keys.

Request: pageCursor - Optional cursor for paginating through results. maxSize - Optional maximum number of results to return per page. includeRevoked - When true, includes revoked keys in the results. includeExpired - When true, includes expired keys in the results.

Response: apiKeys - List of ApiKey objects (id, name, keyHint, timestamps). Full key values are never returned. pagination - Pagination object containing the cursor for the next page.

Security

bearerAuth

Bodyapplication/json

paginationstring or integer

One of:

Rule data fields

string

includeRevokedboolean

includeExpiredboolean

searchQuerystring

Rule data fields

curl -i -X POST \
  https://api.tenovos.net/api/v1/api-key/list-api-keys \
  -H 'Authorization: Bearer <YOUR_JWT_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "includeRevoked": false,
    "pagination": {
      "maxSize": 25
    }
  }'

Responses

OK

Bodyapplication/json

apiKeysArray of objects(tenovos_authz_ApiKey)

pageCursorstring

Rule data fields

Response

application/json

{
  "apiKeys": [
    { … }
  ],
  "pageCursor": "string"
}

Revoke an API key

Request

Revokes an API key, permanently deactivating it so it can no longer be used for authentication.

Request: id - ID of the API key to revoke. Revocation cannot be undone.

Response: apiKey - The ApiKey record with the revokedAt timestamp populated.

Security

bearerAuth

Bodyapplication/json

idstring

Rule data fields

curl -i -X POST \
  https://api.tenovos.net/api/v1/api-key/revoke-api-key \
  -H 'Authorization: Bearer <YOUR_JWT_HERE>' \
  -H 'Content-Type: application/json' \
  -d '{
    "id": "key_01hbgk5cqef94v60bqg6qfv660"
  }'

Responses

OK

Bodyapplication/json

apiKeyobject(tenovos_authz_ApiKey)

Response

application/json

{
  "apiKey": {
    "id": "string",
    "name": "string",
    "keyHint": "string",
    "expiresAt": { … },
    "lastUsedAt": { … },
    "createdAt": { … },
    "revokedAt": { … }
  }
}

Channels

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
enable-channel — activate scanning and webhook registration; channel begins syncing content
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.

Operations

Workflows

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.

Operations

Actions

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.

Operations

Jobs

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

Operations

Share Authentication

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.

Operations

Sharing

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.

Operations

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

Operations

Media Processing

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:

Operation	Examples
Image processing	Resize, crop, format conversion (JPEG, PNG, WebP, AVIF), resolution scaling, thumbnail generation
Video transcoding	Format conversion, bitrate adjustment, preview clip generation
Document conversion	Office/PDF to image preview, page extraction
AI enrichment	Image hash generation, visual feature extraction, content classification, captioning (via AWS Bedrock)

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

Operations

Document Management

Document Types

Document Schemas

Document Rules

Content Storage

Authentication

User Groups

Roles

Users

Permissions

Access Control

API Keys

Create an API key

Request

Responses

Was this helpful?

Search API keys

Request

Responses

Was this helpful?

Revoke an API key

Request

Responses

Was this helpful?

Channels

Workflows

Actions

Jobs

Shared Content

Media Processing

Document Management

Document Types

Document Schemas

Document Rules

Content Storage

Authentication

User Groups

Roles

Users

Permissions

Access Control

API Keys

Create an API key

RequestExpand all

Responses

Was this helpful?

Search API keys

RequestExpand all

Responses

Was this helpful?

Revoke an API key

Request

Responses

Was this helpful?

Channels

Workflows

Actions

Jobs

Share Authentication

Sharing

Shared Content

Media Processing

Request

Request