trigger_type: "schedule") that shows up under GET /flows/definitions/{definition_id}/batches — so everything you already know about batches and executions applies.
How schedules work
When youPOST /flows/schedules with a definition_id and a cron_expression:
- GetDialed creates the record and its backing cron in one call.
- On every cron tick, a new batch is created and the Definition runs with the schedule’s
input_data. next_fire_atis computed at read time from the cron expression — it is never stored.last_fired_at/last_fire_statusare updated by the worker as fired batches start and finish.
Fire policy is not configurable: overlapping fires are skipped (
overlap=SKIP) — if a previous fire is still running when the next tick arrives, that tick is dropped. Missed fires during downtime are replayed only within a 60-second catch-up window; anything older is skipped.Create a schedule
Fire a Definition every 15 minutes. TheX-API-Key header is admin-equivalent; a Clerk JWT needs the admin role.
List your schedules
Results use offset pagination (limit/skip), newest first by default. The response is the standard Page envelope — items, a real total (the filtered count), the echoed limit/skip, and next_cursor (always null on this offset-paginated list). Order with sort_by/order.
Pause and resume
There is no separate pause endpoint — flipenabled with a PATCH. enabled: false pauses the backing schedule; enabled: true unpauses it. Fire history is preserved either way. definition_id is immutable — to point a schedule at a different Definition, delete it and create a new one.
Delete a schedule
Removes the backing cron, then the stored record. Batches already fired by the schedule are unaffected. The delete is idempotent — a missing backing cron still returns204.
Next steps
Schedules
The full object reference, cron rules, and fire semantics.
Batches and executions
Every fire creates a batch — track its lifecycle and executions.