Apply Manifest

Apply a YAML manifest to create resources.

Creates all resources defined in the manifest file in dependency order. Fails if any resource already exists (create-only mode). Performs automatic rollback if any resource creation fails.

Features:

• Topological sorting ensures resources are created in correct dependency order
• Secret references (${{ secrets.NAME }}) are resolved from organization secrets
• Atomic operation: rolls back all created resources if any creation fails
• Dry run mode validates the manifest without making changes

Example:

curl -X POST /v1/manifest/apply \
  -H "Authorization: Bearer $API_KEY" \
  -H "X-Namespace: ns_xxx" \
  -F "manifest_file=@mixpeek.yaml"

Example manifest:

version: "1.0"
metadata:
  name: "my-environment"

namespaces:
  - name: video_search
    feature_extractors:
      - name: multimodal_extractor
        version: v1

buckets:
  - name: raw_videos
    namespace: video_search
    schema:
      properties:
        video: { type: video }

POST /v1/manifest/apply

Apply Manifest

cURL

curl --request POST \
  --url https://api.mixpeek.com/v1/manifest/apply \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: multipart/form-data' \
  --form manifest_file='@example-file'

201

{
  "success": true,
  "resources": [
    {
      "resource_type": "<string>",
      "name": "<string>",
      "resource_id": "<string>",
      "error": "<string>"
    }
  ],
  "created_count": 0,
  "failed_count": 0,
  "skipped_count": 0,
  "errors": [
    "<string>"
  ],
  "warnings": [
    "<string>"
  ],
  "rollback_performed": false,
  "rollback_orphans": [
    "<string>"
  ],
  "dry_run": false
}

Authorizations

Authorization · string · header · required

Mixpeek API key, sent as Authorization: Bearer mxp_sk_.... Create one in Studio under Settings → API Keys, or with an admin key via POST /v1/organizations/users/{user_email}/api-keys. A missing header returns 403; an invalid or revoked key returns 401.

Query Parameters

dry_run · boolean · default: false

Validate only, don't create resources

Body

multipart/form-data

manifest_file · file · required

YAML manifest file

Response

201

application/json

Successful Response

Result of applying a manifest.

success · boolean · required

Whether all resources were created successfully

resources · ResourceResult · object[]

Results for each resource

Show child attributes

created_count · integer · default: 0

Number of resources created

failed_count · integer · default: 0

Number of resources that failed

skipped_count · integer · default: 0

Number of resources skipped

errors · string[]

Error messages

warnings · string[]

Non-fatal issues found while PARSING the manifest, chiefly keys the parser had to drop. MG-1435: the parser already detects these and /validate and /lint already surface them, but /apply computed them and threw them away — so anyone applying without validating first got a 201 and no hint that part of their manifest was ignored. A collection-level field_passthrough: is the case that cost a customer POC: detected, described, discarded.

rollback_performed · boolean · default: false

Whether a rollback was ATTEMPTED after a failure. MG-1440: this used to read as 'the namespace was returned to its prior state', which it does not mean — rollback deletes only namespaces and buckets today, so any other resource created before the failure SURVIVES. Read rollback_orphans to find out what is still there.

rollback_orphans · string[]

Resources created before the failure that rollback did NOT delete, as '/'. Non-empty means the namespace is in a PARTIAL state and a straight retry will hit AlreadyExists on these. MG-1440: previously these were silently skipped while rollback_performed=true claimed otherwise, which is the state that had to be unpicked by hand on the Radio-Canada POC.

dry_run · boolean · default: false

Whether this was a dry run (no changes made)