Create a new workflow. Optionally provide steps to define the workflow’s step graph.
When steps is omitted, the workflow is created with default steps (TRIGGER → PARSE). When steps is provided, the step graph is validated and the draft version is populated with the given steps.
Note: The default steps may change in the future. If your integration depends on a specific step graph, provide steps explicitly.
Bearer authentication of the form Bearer <token>, where token is your auth token.
The type of object. Always "workflow".
The time (in UTC) at which the object was created. Will follow the RFC 3339 format.
Example: "2024-03-21T16:45:00Z"
The time (in UTC) at which the object was last updated. Will follow the RFC 3339 format.
Example: "2024-03-21T16:45:00Z"
API version to use for the request. If you’re using an SDK, you can ignore this parameter. If you are not using an SDK and do not specify a version, you will either receive a 400 Bad Request or be set to a previous legacy version. See API Versioning for more details.
The steps that define the workflow’s processing graph. Each step has a type, a unique name, and optional next entries that define routing to downstream steps.
When omitted, the workflow is created with default steps (TRIGGER → PARSE). The default steps may change in the future.
See the Configuring Workflows via API guide for step definitions, branching patterns, and examples.