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

/api/v1/media
List media metadata for the routed project and environment.
Scope required: media:read
q
string
Case-insensitive filename search. Blank strings are ignored.
category
string
Filter by derived category: image, video, audio, document, archive, or other.
uploadedBy
string
Filter by the uploading user ID.
uploadedFrom
string
Include assets uploaded on or after this YYYY-MM-DD date.
uploadedTo
string
Include assets uploaded through this YYYY-MM-DD date.
sort
string
Sort by uploadedAt, filename, or sizeBytes. Defaults to uploadedAt.
order
string
Sort direction: asc or desc. Defaults to desc for uploadedAt and sizeBytes, and asc for filename.
limit
number
Page size from 1 to 100. Defaults to 30.
offset
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

/api/v1/media/upload
Upload a file. The request must use multipart/form-data encoding.
Scope required: media:upload Content-Type: multipart/form-data
file
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

/api/v1/media/{id}
Read metadata for one media asset in the routed project and environment.
Scope required: media:read

Path Parameters

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

Delete Media

/api/v1/media/{id}
Delete a media file. This removes the file from storage and invalidates all URLs.
Scope required: media:delete

Path Parameters

id
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

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

Create Webhook

/api/v1/webhooks
Register a new webhook endpoint.
Scope required: webhooks:write
url
string
required
The HTTPS URL to receive webhook payloads. Must use HTTPS.
events
string[]
required
List of event types to subscribe to. See Event Types below.
secret
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.
active
boolean
Whether the webhook is active. Defaults to true.
Example request:
Response:

Update Webhook

/api/v1/webhooks/{id}
Update an existing webhook configuration.
Scope required: webhooks:write

Path Parameters

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

Delete Webhook

/api/v1/webhooks/{id}
Remove a webhook configuration. Pending deliveries are cancelled.
Scope required: webhooks:write

Path Parameters

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