Introduction
What open-videocore is, how it's put together, and the ideas you need before your first API call.
What open-videocore is
open-videocore is headless, API-first media asset management (MAM) middleware. It doesn't do any media processing itself — it orchestrates OSC services that do (a transcoder, a packager, object storage, a metadata store) behind one small, versioned REST API. You call one API; open-videocore routes the work to the right backing services and tracks the result as an asset.
Each workspace — a named stack you provision once — owns its own object storage, metadata store, and queue. Nothing is shared across workspaces at the data layer; the middleware resolves the right backing services for each request from a parameter store, so there are no static connection strings to manage per workspace.
REST basics
- Base URL. Every endpoint in this documentation is relative to your instance's public URL:
https://<your-instance>. - JSON everywhere. Request and response bodies are JSON (
Content-Type: application/json), except raw media bytes on upload endpoints and YAML on profile endpoints. - Versioning. The entire API is namespaced under
/api/v1. There is no separate per-resource version. - Collection roots and the trailing slash. A collection root like
POST /api/v1/assetsis served both with and without a trailing slash — both reach the same handler. This documentation uses whichever form the spec emits internally; either works at runtime.
Identifiers
Every entity — asset, job, collection, webhook, profile, provisioning operation — has an opaque string id (or, for profiles, a unique name) assigned by the server on creation. IDs are not guessable and should be treated as opaque tokens, not parsed.
Timestamps
Entity timestamps (createdAt, updatedAt, and each asset's statusHistory[].at) are ISO 8601 date-time strings in UTC, e.g. 2026-09-03T12:00:00.000Z. Job progress timestamps (startedAt, completedAt on a provisioning operation) are Unix epoch milliseconds — check the field's type in the reference before assuming one or the other.
Synchronous vs. asynchronous work
Reads and small writes (create a collection, add a tag, update metadata) respond immediately. Anything that touches media or infrastructure — ingest, transcode, package, clip, export, provisioning — is asynchronous: the triggering call returns a Job or Provisioning Operation immediately, and you poll its own GET endpoint for completion. See each capability's guide for the exact job type it returns.