Publishing

Publishing is what makes a workflow runnable from outside Studio. Until you publish, every external trigger — API, webhook, form, and schedule alike — behaves as though the workflow does not exist.

Publishing happens in Studio. There is no public-API endpoint for it, deliberately: it is a deploy action with an audit trail, not something an integration should do on its own.

What a publish actually does

One atomic step, four effects:

1. The workflow is flagged published.
2. A deployment record is created, pinning the workflow's newest saved version, and recording who deployed it and when.
3. The Recurrence schedule is reconciled — created, updated to the newly pinned version, or left alone if the graph has no Recurrence node.
4. A Form Trigger's public URL is minted or carried forward, and its auth mode and credentials are applied — see Triggers. A graph with no Form Trigger node gets none.

The flag and the deployment land together or not at all. A workflow flagged published with nothing behind it would be a workflow you believe is live and which nothing can actually trigger.

Runs are version-pinned

An external run executes the version the active deployment pins — never "the newest saved version".

This distinction is the whole point of a deployment record. Studio's own Run button behaves differently on purpose: it runs the draft you are currently editing, because that is what an author testing a change wants. If external triggers did the same, every unsaved-but-saved-as-a-version experiment would go straight into production the moment it touched the canvas.

So: editing a published workflow changes nothing for your integration until you publish again.

Republishing

Publishing again pins the newest version, deprecates the previous deployment, and updates the Recurrence schedule to fire the new version.

The webhook and form URLs are carried forward unchanged. A republish never invalidates a URL you have already handed to a third-party system or to a person filling in a form — deployment history keeps the same tokens, and only the active deployment resolves. A form's Basic password is likewise kept unless this publish sets a new one.

Runs already in flight against the previous version are unaffected; they finish on the graph they started with.

Unpublishing

Unpublishing takes the workflow out of service: the published flag is cleared, the active deployment is deprecated, and any Recurrence schedule is removed.

After that:

• POST /workflows/:id/run and /run-async return 409 workflow_not_published.
• The webhook URL returns 404.
• The form URL returns 404, with the same deliberately uninformative body.
• The schedule stops firing.

Both the published flag and the active deployment are checked on every external run, independently. That redundancy is deliberate: the deprecation write during unpublish is best-effort, so a deployment record that survives it must not keep the workflow externally runnable.

The error you will see

409 Conflict
{
  "error": "workflow_not_published",
  "message": "This workflow has no active deployment. Publish it before running it through the API."
}

409 rather than 422: the request itself is fine — it is the workflow's current state that does not support running it. A run is never silently fulfilled by falling back to a draft.

Where to go next

• Triggers — the four ways to start a published workflow.
• Workflows API reference — the endpoints themselves.