REST API
Everything the console does, it does over this API. Your master serves its own interactive schema — this page is the orientation.
The authoritative reference#
The master generates an interactive API reference from the running code and serves it alongside the console. It is always current for the version you are actually running, which a written list of endpoints cannot be.
| Path on your master | What it is |
|---|---|
/docs | Interactive reference — every endpoint, with a try-it form. |
/redoc | The same schema in a reading layout. |
/openapi.json | The raw OpenAPI document — feed this to a client generator. |
/docs on your master is the API schema. The pages you are reading now are the product documentation. They are different servers.
Authenticating#
Every endpoint except login requires a bearer token. Exchange credentials for one:
$ curl -X POST https://master.studio.local:7443/auth/login \
-d '{"username": "admin", "password": "…"}'Then send it on every request:
$ curl https://master.studio.local:7443/workers \
-H "Authorization: Bearer $TOKEN"Login is rate-limited, and a session token is meant for a person at a browser. For automation, issue a dedicated API token instead — it is revocable on its own, so turning off one integration does not mean changing an administrator password that other things depend on.
Submitting a job#
The one call most integrations need. A source the master can read, a preset id, and where to write the result:
Human-readable job name, as it will appear in the queue.
The source. Must be readable by the master— its filesystem is what matters, not the caller's.
Where the finished file is written. Also the master's filesystem.
Required when choosing the preset yourself. Ignored when you let the selector choose.
Who picks the preset. Defaults to naming it yourself.
Scheduling priority for this job.
A successful call returns 201 with the created job, including the chunk plan. Submission is where a bad source path is caught — the master probes before planning, and a source it cannot read fails here rather than on a worker later.
What is exposed#
The console has no private API. Everything it does is available to you, across roughly forty resource areas. The ones most integrations touch:
| Area | For |
|---|---|
/jobs | Submit, list, cancel, retry, and read per-job forensics. |
/workers | Fleet state, approval, draining. |
/presets | The library, including ids for submission. |
/watch-rules | Watch-folder automation. |
/qc · /lineage | Quality-control results and how an output was produced. |
/api-tokens | Tokens for automation. |
/system | Pause and resume the fleet. Administrator only. |
Beyond these are the shot and ingest domains, MAM connectors, review and approvals, storage, alerts and more. The interactive reference on your master lists all of them with their exact shapes.
Conventions#
- Bearer auth on everything. A missing or expired token is a
401. - Roles are enforced server-side. Some endpoints require an administrator; a valid token is not automatically a permitted one.
- Every response carries a request id. The
x-request-idheader ties a call to its entry in the activity log — quote it when reporting a problem. - Login is rate-limited. Use an API token for anything automated.
- Live progress is a WebSocket. Do not poll a job to watch it — subscribe, as the console does.
Some endpoints restore databases, write to NLE project files, or pause the fleet. They are protected by role, not by being hidden. Give automation a token with the access it needs and no more.