Skip to main content
Playbooks are read-only over the API: GET /v1/projects/{project_id}/playbooks lists them, and there is no create. A playbook has to exist (authored in the app, or by Addison) before anything else here applies. Schedules are how you run one programmatically. Product-side docs: Playbooks.
Schedule runs send real email to the recipients they name, immediately, and a run cannot be recalled. Keep the recipient list empty while you iterate.

Create a playbook

Playbooks are authored by asking Addison inside a project. That path works over the API today, through the conversations endpoints. Describe the analysis, the outputs, and the parameters you want, and Addison writes the .spb.

Find and open playbooks

GET /v1/projects/{project_id}/playbooks

List a project’s playbooks.

GET /v1/projects/{project_id}/playbooks/{playbook_id}

Show a single playbook.

What’s in a playbook

GET /v1/projects/{project_id}/playbooks/{playbook_id}

Show a playbook, including its manifest: title, description, parameters, and data context.

Run a playbook

POST /v1/schedules/{schedule_id}/runs

Run a schedule’s playbook immediately, without waiting for its next occurrence.
Until then, a paused schedule is how you run a playbook over the API. Create one with paused set so it cannot fire on its own, then trigger it by hand. The run is real; the cadence never starts.
Leave the recipient list empty while you are still iterating. Running a schedule delivers real email immediately, and a manual run cannot be recalled once it has gone.

Schedule a playbook

GET /v1/schedules

List schedules.

POST /v1/schedules

Create a schedule.

GET /v1/schedules/{schedule_id}

Show a schedule.

PUT /v1/schedules/{schedule_id}

Update a schedule.

POST /v1/schedules/{schedule_id}/pause

Pause a schedule.

POST /v1/schedules/{schedule_id}/resume

Resume a schedule.

DELETE /v1/schedules/{schedule_id}

Delete a schedule.

Run history

GET /v1/schedules/{schedule_id}/runs

List a schedule’s runs.

Rename, copy, and download