Schedule schemas

​

Schedule object

Create, get, list, update, archive, pause, and unpause endpoints return this structure.

​

Execution policy

​

Trigger policy

See Create a schedule for the public format and constraints of sinks.

​

Schedule Run object

Run, get Run, and list Runs endpoints return this structure. Main execution status and IM delivery push_status are independent. When the Schedule has execution.max_attempts=2, the same Run may ultimately return attempt=2.

​

Input version

initial_events_version is maintained by the server and must not be supplied in create or update requests. A new Schedule starts at 1. The version increments only when the normalized initial_events content actually changes. Submitting identical content or changing the name, execution policy, or trigger policy does not increment it. Restoring previously used content creates a new version. For existing Schedules, the current input starts at 1; historical versions are not reconstructed. A Run is not bound to input when it is created. Before sending input for the first time in an attempt, the executor binds the matching content and version to the Run. Send retries and recovery within the same attempt reuse that binding; a new attempt may select updated input. Interpret the version together with attempt: its presence means that input has been selected, not that the runtime has received it or executed it successfully. The field is omitted for pending or skipped Runs that have not selected input, and for historical Runs whose execution input cannot be confirmed. An unknown version is not returned as 0 and must not be filled with the current Schedule version. Clients should tolerate the added field and treat a missing version as unknown. After creating or updating a Schedule, integrations can store the mapping between schedule_id, initial_events_version, and input content, then correlate execution input using the version in a Run or Webhook callback. The current Schedule returns the latest configuration, which may differ from that of a Run that has already started.

​

Creation source

source and source_session_id are read-only fields that are always present in complete v1/v2 Schedule and Schedule Run responses. The server records the source. It cannot be set in create or update requests, and filtering by source is not supported. metadata.source is mutable business metadata and does not represent the authoritative source. A Schedule Run inherits its parent Schedule's source, regardless of whether this Run was triggered manually or automatically, or whether sinks are configured. This also applies to historical Runs and Runs of archived Schedules. The Run's session_id identifies its execution Session; trigger_context.type identifies how this Run was triggered. The originating Session does not indicate an execution binding for reuse_session, and internal origin-result delivery targets are not exposed as the public source. The source fields are backward-compatible JSON additions; clients should tolerate unknown fields. After service deployment, query responses for historical Schedules and Runs also return these fields without a data backfill.

​

Trigger Context

​

Run Error

error may be returned when status=failed or status=skipped; it is null when status=completed.