Skip to main content

Schedules

Status: Current (Scale plan). A schedule is a standing recurring cadence over one account’s existing content. A materializer runs every 5 minutes, turning each active schedule into video-only queued runs spread across its active window; your own runner drains them. Recurrence defaults to draft disposition — it is opt-in to live. All paths are relative to <baseUrl>/v1 and require Authorization: Bearer. Reads need schedules:read; writes need schedules:write; the schedule’s own runs read need runs:read.

Endpoints

Create a schedule — POST /v1/schedules

Returns 201 with { "schedule": Schedule }. 422 on an invalid timezone / window / shape; 404 if the account or device is not in your org; 413 if the per-org schedule cap is reached.

List / get

GET /v1/schedules takes status, account, limit (1–200, default 50) and returns { "schedules": Schedule[] }, newest first. GET /v1/schedules/{id} returns { "schedule": Schedule } or 404.

Update — PATCH /v1/schedules/{id}

The body is the patch. Patchable fields: name, cadence, device_udid, active_start_hour, active_end_hour, timezone, per_day_cap, horizon_hours, default_disposition. Any other key is rejected 422.
account_username is not patchable — to retarget a schedule, delete and recreate it. status is not patchable either — status changes go through pause / resume / delete.

Pause / resume

  • POST /v1/schedules/{id}/pause stops materializing and cancels the schedule’s future queued runs (claimed/running runs complete), so nothing new fires after you pause.
  • POST /v1/schedules/{id}/resume sets status back to active. It is forward-only — slots canceled during the pause are not back-filled.
Each returns { "schedule": Schedule }.

Delete — DELETE /v1/schedules/{id}

A soft delete: sets status=deleted and cancels future queued runs. Never a hard delete. Returns { "schedule_id", "status": "deleted" }.

Runs from a schedule — GET /v1/schedules/{id}/runs

Query: status, limit. Returns { "runs": Run[] } — the runs this schedule materialized, newest fire first. Gated on runs:read because it returns run data. See the Run object.

The Schedule object

Next

  • Runs — the runs a schedule produces.
  • Webhooks — notifications as those runs complete or fail.