Skip to main content

Media API

The Media API uploads, lists, reads, and deletes project-scoped media assets. Media files are stored in S3-compatible object storage, and each request is routed to an explicit project and environment target. All /api/v1/media* endpoints require X-MDCMS-Project and X-MDCMS-Environment headers.

List Media

List media metadata for the routed project and environment.
Scope required: media:read
string
Case-insensitive filename search. Blank strings are ignored.
string
Filter by derived category: image, video, audio, document, archive, or other.
string
Filter by the uploading user ID.
string
Include assets uploaded on or after this YYYY-MM-DD date.
string
Include assets uploaded through this YYYY-MM-DD date.
string
Sort by uploadedAt, filename, or sizeBytes. Defaults to uploadedAt.
string
Sort direction: asc or desc. Defaults to desc for uploadedAt and sizeBytes, and asc for filename.
number
Page size from 1 to 100. Defaults to 30.
number
Zero-based page offset. Defaults to 0.
Duplicate query parameters, unknown query parameters, invalid dates, and inverted date ranges return INVALID_QUERY_PARAM. Example request:
Response:

Upload Media

Upload a file. The request must use multipart/form-data encoding.
Scope required: media:upload Content-Type: multipart/form-data
file
required
The file to upload. Image uploads are limited by the routed project’s media image upload setting when configured. Non-image uploads are not subject to that image limit.
Example request:
Response:

Get Media

Read metadata for one media asset in the routed project and environment.
Scope required: media:read

Path Parameters

string
required
The media asset ID.
Example request:
Response:

Delete Media

Delete a media file. This removes the file from storage and invalidates all URLs.
Scope required: media:delete

Path Parameters

string
required
The media asset ID.
Example request:
Response:
Media deletion is permanent and cannot be undone. Ensure no documents reference the file before deleting. The API does not scan or rewrite content references.

Webhooks API

Webhooks let you receive real-time HTTP notifications when content changes occur in your project. Configure webhook endpoints to trigger builds, invalidate caches, or sync data with external systems.
The Webhooks API is a post-MVP feature. The endpoints are defined and will be available in an upcoming release.

List Webhooks

Returns all webhook configurations for the current project.
Scope required: webhooks:read Example request:
Response:

Create Webhook

Register a new webhook endpoint.
Scope required: webhooks:write
string
required
The HTTPS URL to receive webhook payloads. Must use HTTPS.
string[]
required
List of event types to subscribe to. See Event Types below.
string
required
Shared signing secret for HMAC signature verification. Must be 32 to 4096 characters. Studio generates this value automatically for new webhooks; API clients must provide a cryptographically random value.
boolean
Whether the webhook is active. Defaults to true.
Example request:
Response:

Update Webhook

Update an existing webhook configuration.
Scope required: webhooks:write

Path Parameters

string
required
The webhook ID.
string
Updated HTTPS URL.
string[]
Updated event subscriptions.
string
Updated shared signing secret. Omit this field to preserve the existing write-only secret.
boolean
Enable or disable the webhook.
Example request:
Response:

Delete Webhook

Remove a webhook configuration. Pending deliveries are cancelled.
Scope required: webhooks:write

Path Parameters

string
required
The webhook ID.
Example request:
Response:

Event Types

Webhook Payload

All webhook deliveries use the following envelope:

Signature Verification

Every webhook delivery includes an X-MDCMS-Signature header for payload verification:
The signature is an HMAC-SHA256 digest computed over the concatenation of the timestamp and the raw request body, using the webhook’s secret as the key. The raw body must be the exact bytes MDCMS sent; parsing JSON and serializing it again can change whitespace or key order and invalidate the signature. Verification algorithm:
  1. Extract the t (timestamp) and v1 (signature) values from the header.
  2. Construct the signed payload: {timestamp}.{raw_body}.
  3. Compute HMAC-SHA256(secret, signed_payload).
  4. Compare the computed digest with the v1 value (use constant-time comparison).
  5. Optionally, reject payloads where the timestamp is more than 5 minutes old to prevent replay attacks.
Verification helper (Node.js):
Express receiver example:

Delivery Behavior

  • Async delivery — Webhooks are dispatched asynchronously and do not block the originating API request.
  • Retries — Failed deliveries (non-2xx responses or network errors) use three total attempts: the initial attempt, then retries after 1 second and 2 seconds.
  • HTTPS only — Webhook URLs must use HTTPS. HTTP URLs are rejected at configuration time.
  • Timeout — Each delivery attempt has a 10-second timeout. If the endpoint does not respond within 10 seconds, the attempt is marked as failed.
Return a 200 status code as quickly as possible from your webhook endpoint. Perform any heavy processing asynchronously to avoid timeouts.