Your API keys must have either Bolt Schedules Admin or Bolt Schedules Metadata Viewer capabilities.
The Bolt API allows you to easily manage and control Bolt schedules and runs within your workspace.
Schedules are identified by slug. The triggerBoltRun, retryBoltRunFromFailure, boltScheduleName, suspendBoltSchedule, listBoltRuns, and deleteBoltSchedule operations all take a slug: String argument — the identifier returned by createBoltSchedule and shown in the Bolt UI.
The examples below authenticate with an account API key — pass Authorization: Bearer <token> and X-Paradime-Workspace: <workspace_uid> (the account key starts with prdm_cmp_). Legacy workspace API keys are still supported: send X-API-KEY and X-API-SECRET headers instead. See API Keys.
List Bolt schedules
This endpoint will return the active Bolt schedules in your workspace.
This endpoint returns the schedule names and slugs across all workspaces in your account, together with the workspace each one belongs to. This is useful with an account API key, where a single credential can operate across multiple workspaces.
Example Request
Example response
List runs for a schedule
This endpoint returns the runs for a given Bolt schedule, identified by its slug.
Example Request
Example response
Get Bolt schedule details
This endpoint will enable you to check the status of a schedule by passing a Bolt schedule slug.
Example Request
Example response
Trigger a Bolt run
This endpoint will enable you to trigger a Bolt schedule run by passing a schedule slug.
Example Request
Example response
Trigger a Bolt run with custom commands
This endpoint will enable you to trigger a Bolt schedule with a custom command and overwrite the actual commands defined in the schedule for that particular run.
This only modifies the command at runtime for the triggered Bolt schedule and not the commands configuration defined in the schedule.
Example Request
Example response
Trigger a Bolt run with a custom git branch
This endpoint will enable you to trigger a Bolt schedule with a custom git commit and overwrite the branch name defined in the schedule configuration.
This only modifies the commit at runtime for the triggered Bolt schedule and not the branch name defined in the schedule.
Example Request
Example response
Trigger a Bolt run with a PR number
This endpoint enables you to trigger a Bolt schedule with a specific pull request number, which is particularly useful for Turbo CI workflows that need to associate runs with pull requests for smart cancellation and concurrency enabedled.
Example response
Trigger a Bolt run with a reason
This endpoint enables you to trigger a Bolt schedule with a freeform reason describing why or from where the run was triggered (e.g. the application that made the call). The reason is stored with the run for context and auditing.
Example response
Cancel a Bolt run
This endpoint will enable you to cancel a Bolt run by passing the runID of a Bolt schedule.
Example Request
Example response
Retry a Bolt Run
Retry the latest failed run of a schedule by slug
This endpoint will enable you to retry the latest failed run of a Bolt schedule by passing only the schedule slug — no run ID required. The retry resumes from the failed command of the most recent run of the schedule. The first failed dbt command is automatically substituted with dbt retry when supported. Infrastructure commands (git clone, dbt deps) are skipped — they run automatically on every Bolt run.
A new Bolt run is created and its runId is returned. The original failed run is unchanged.
Example Request
Example response
This endpoint will return an error if:
the schedule has no runs yet
the latest run is still in progress
the latest run has no commands to retry
all commands in the latest run succeeded — in this case, there is nothing to retry.
Retry a failed Bolt run by ID (failed commands only)
This endpoint will enable you to retry a failed Bolt run by re-running only the failed commands. The first failed dbt command is automatically substituted with dbt retry when supported, re-running just the failed models. Infrastructure commands (git clone, dbt deps) are skipped — they run automatically on every Bolt run.
A new Bolt run is created and its runId is returned. The original failed run is unchanged.
Example Request
Example response
This endpoint will return an error if:
the original run is still in progress (Cannot retry a run that is still in progress)
the original run has no commands to retry (Schedule run has no commands to retry)
all original commands succeeded (All commands were successful, nothing to retry)
only infrastructure commands (git clone, dbt deps) failed — in this case, trigger the original schedule again instead.
Retry a Bolt run by ID (all commands)
This endpoint will enable you to retry a Bolt run by re-running every original command verbatim, regardless of which ones succeeded or failed. Infrastructure commands (git clone, dbt deps) are excluded — they run automatically on every Bolt run.
A new Bolt run is created and its runId is returned. The original run is unchanged.
Example Request
Example response
Get Bolt run status
This endpoint will enable you to check the status of a Bolt run run by passing the runID.
Example Request
Example response
Get Bolt command details
This endpoint will enable you to extract for a given command all the related details including raw error logs by passing a commandId. This is normally used in conjunction with the Paradime Webhooks.
Example Request
Example response
Get Bolt command live logs
This endpoint streams stdout and stderr for a Bolt command while it is still running — useful for tailing a run in real time rather than waiting for it to finish and reading the final logs from boltCommand.
The query is cursor-paginated:
Pass cursor: "0:0" on the first call to fetch from the beginning of the command's output.
Each response includes a new cursor — pass it back into the next call to fetch only new lines.
When the command finishes, finished returns true. Stop polling.
Each line carries a stream field of either STDOUT or STDERR. Within a batch, STDOUT lines precede STDERR lines — true cross-stream ordering is not recorded.
Example Request
Example response
When the command has exited, the response looks like:
Get Bolt command resource URL
This endpoint will enable you to extract for a given command the related resource generated by the execution of the command, for example the run_results.json or the manifest.json by passing a resourceId. This is normally used in conjunction with the Paradime Webhooks.
Example Request
Example response
Create a Bolt schedule
This mutation creates a new Bolt schedule and returns its slug. The slug is the identifier you pass to every other Bolt endpoint (triggerBoltRun, boltScheduleName, deleteBoltSchedule, etc.).
The required input fields are name, schedule, environment, and commands. The BoltScheduleInput type also supports a wide set of optional fields (gitBranch, description, timezone, ownerEmail, suspended, slaSeconds, triggerOnMerge) plus nested objects for notifications, third-party incident integrations, the self-healing agent, Turbo CI / deferred-schedule config, parent-schedule triggers, and environment-variable overrides.
There is a short consistency window (~10s) between schedule creation and the trigger path accepting the new slug. Clients that immediately call triggerBoltRun on a brand-new slug may need to retry for a few seconds.
Minimal create
Example Request
Example response
Create with notifications, env vars, and self-healing
The same mutation, with the optional nested objects populated.
Example Request
Suspend or resume a Bolt schedule
This mutation suspends or resumes a Bolt schedule by slug. Pass suspend: true to suspend the schedule (pausing its time-based runs) or suspend: false to resume it.
Example Request
Example response
Delete a Bolt schedule
This mutation deletes a Bolt schedule by slug. Schedules defined in YAML cannot be deleted via the API — remove them from the repository instead.
Example Request
Example response
This endpoint will return an error if the slug does not match a UI/API-created schedule in the workspace (e.g. it belongs to a YAML-defined schedule, has already been deleted, or never existed).