curl, jq, and uuidgen. Set an API credential with permission to create and read runs and manage schedules in the project. The example uses a task named daily-summary in support-assistant. Implement the task before running it. Creating task metadata alone does not implement its behavior.
1. Run the task once
Start the task withPOST /runs. Replace <PROJECT_ID> with the project’s UUID:
run-task.sh
id. Acceptance means the run was created, not that the task finished successfully.
Reuse the same idempotency key and request body when retrying this request. Use a new key for a separate run. A credential without read access receives only run_id and status; this walkthrough requires read access.
The task runs against the main-branch deployment by default. If the task requires input, add its declared business input under input. The same input must be configured for scheduled executions.
2. Verify the one-off result
PollGET /runs/{run_id} until the run completes or needs attention:
wait-for-task.sh
3. Create a recurring schedule
Schedule the task withPOST /projects/{project_reference}/schedules:
schedule-task.sh
schedule object. Confirm its status is active. This schedule runs at 08:00 UTC each day. Forbid prevents overlapping runs from this schedule.
Verify the result
Check the saved schedule’s target, timezone, and status. Each scheduled execution creates a separate run to inspect. Use a workflow when the implementation needs multiple coordinated steps. For a workflow run, settarget.type to workflow and supply its definition ID and declared input. Schedule targets use kind, while direct run targets use type.