Prerequisites:
- This feature is available with the Paradime Bolt plan.
- Your API keys must have either Bolt Schedules Admin or Bolt Schedules Metadata Viewer capabilities.
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 returns the Bolt schedules in your workspace’s current configuration. SetshowInactive: true to get the inactive schedules instead: schedules that are no longer in your current configuration, for example ones you have deleted. Their runs stay available through listBoltRuns. The two lists do not overlap, so call the endpoint with both values to cover every schedule.
Example Request
- GraphQL
- cURL
Example response
Example response
List schedules across all workspaces
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- GraphQL
- cURL
Example response
Example response
List runs for a schedule
This endpoint returns the runs for a given Bolt schedule, identified by itsslug. Runs come back newest first, up to 1000 per call. Use offset to page through older runs.
Example Request
- GraphQL
- cURL
Example response
Example response
Get Bolt schedule details
This endpoint will enable you to check the status of a schedule by passing a Bolt scheduleslug.
Example Request
- GraphQL
- cURL
Example response
Example response
Trigger a Bolt run
This endpoint will enable you to trigger a Bolt schedule run by passing a scheduleslug.
Example Request
- GraphQL
- cURL
Example response
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.triggerBoltRun also accepts commandConfigs: [BoltCommandInput] (each entry is {command, continueOnError}) instead of commands, plus a run-level continueOnError: Boolean default, so an ad-hoc run can keep going past a failed command. Pass exactly one of commands or commandConfigs.- GraphQL
- cURL
Example response
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.If
branch isn’t the schedule’s own branch (or, for a schedule without a branch, the workspace’s default branch), schedules with an On run completion trigger on this schedule don’t start after the run. The run page shows a Branch override pill.- GraphQL
- cURL
Example response
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.- GraphQL
- cURL
Example response
Example response
Trigger a Bolt run with a reason
This endpoint enables you to trigger a Bolt schedule with a freeformreason 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.
- GraphQL
- cURL
Example response
Example response
Cancel a Bolt run
This endpoint will enable you to cancel a Bolt run by passing therunID of a Bolt schedule.
Example Request
- GraphQL
- cURL
Example response
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 scheduleslug — 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
- GraphQL
- cURL
Example response
Example response
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 withdbt 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
- GraphQL
- cURL
Example response
Example response
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
- GraphQL
- cURL
Example response
Example response
Get Bolt run status
This endpoint will enable you to check the status of a Bolt run run by passing therunID.
Example Request
- GraphQL
- cURL
Example response
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 acommandId. This is normally used in conjunction with the Paradime Webhooks.
Example Request
- GraphQL
- cURL
Example response
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 fromboltCommand.
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,
finishedreturnstrue. Stop polling. - Each line carries a
streamfield of eitherSTDOUTorSTDERR. Within a batch,STDOUTlines precedeSTDERRlines — true cross-stream ordering is not recorded.
- GraphQL
- cURL
Example response
Example response
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 therun_results.json or the manifest.json by passing a resourceId. This is normally used in conjunction with the Paradime Webhooks.
Example Request
- GraphQL
- cURL
Example response
Example response
Create a Bolt schedule
This mutation creates a new Bolt schedule and returns itsslug. 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 the command list. Commands are passed as exactly one of two fields: the plain commands: [String] list, or commandConfigs: [BoltCommandInput] where each entry is {command, continueOnError} for per-command failure handling. The BoltScheduleInput type also supports a wide set of optional fields (gitBranch, description, timezone, ownerEmail, suspended, slaSeconds, triggerOnMerge, continueOnError) 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.
Continue on error: by default a failed command skips the remaining commands in the run. Set continueOnError: true at the schedule level to keep running after a failure, and use commandConfigs to override the behavior per command (continueOnError: null inherits the schedule default). The run is still reported as failed. For example:
- GraphQL
- cURL
Example response
Example response
Create with notifications, env vars, and self-healing
The same mutation, with the optional nested objects populated. Example Request- GraphQL
Suspend or resume a Bolt schedule
This mutation suspends or resumes a Bolt schedule byslug. Pass suspend: true to suspend the schedule (pausing its time-based runs) or suspend: false to resume it.
Example Request
- GraphQL
- cURL
Example response
Example response
Delete a Bolt schedule
This mutation deletes a Bolt schedule byslug. Schedules defined in YAML cannot be deleted via the API — remove them from the repository instead.
Example Request
- GraphQL
- cURL
Example response
Example response
FAQ
How do I get the debug logs for a command?
How do I get the debug logs for a command?
The Debug logs toggle on a run page shows dbt™‘s
logs/dbt.log file for that command, which holds the debug-level output. The stdout and stderr fields that boltRunStatus and boltCommand return are the console logs.To download the debug log:- Call
boltCommand(commandId)and find the resource whosepathislogs/dbt.log. - Pass its
idtoboltResourceUrlto get a download URL.
bolt.run.completed webhook, each command’s api_query is this same boltCommand query. The payload’s json_resources lists only the JSON artifacts under target/, so the log file is not in it.How do I list every run ID?
How do I list every run ID?
- List your schedules with
listBoltSchedules, once withshowInactive: falseand once withshowInactive: true. The second call returns only the schedules that are no longer in your configuration, so you need both. - For each slug, page through
listBoltRunswithoffsetuntil a call returns fewer runs than yourlimit. Runs come back newest first, up to 1000 per call.
bolt.run.started and bolt.run.completed webhooks. Both carry the run ID in their id field.