For the complete documentation index, see llms.txt. This page is also available as Markdown.

Publishing & versioning

Publishing turns a pipeline into a versioned HTTP endpoint. This page covers how versions work, how to roll back, and how to read run history.


Draft vs. published

Every pipeline has two states:

  • Draft - the graph you edit on the canvas. Running from the editor executes the draft.

  • Published - a frozen snapshot that serves API traffic. The /invoke and /chat/completions endpoints always run the published snapshot, never your in-progress draft.

This separation means you can keep editing a live pipeline without affecting production calls until you publish again.


Versions

Each time you publish, Treza snapshots the current graph and assigns it an incrementing version number. The version is returned on every API response (the version field on /invoke, and the x-treza-pipeline-version header on /chat/completions), so you always know which snapshot produced a result.

  • Re-publish to cut a new version after editing the draft.

  • API keys and the endpoint URL stay the same across versions. Only the running snapshot changes.


Rollback

If a new version misbehaves, roll back to an earlier one from the pipeline's publishing controls. Rollback re-points the published snapshot at a previous version without changing your draft, so live traffic recovers immediately while you fix the draft.


Run history

Every execution, whether triggered from the editor or over the API, is recorded as a run. Each run captures:

  • Per-node timing - how long each node took.

  • Tokens and cost - token counts and the provider cost charged.

  • Status - success or error, with the failing node surfaced on errors.

  • Trigger - whether the run came from the editor or the API.

  • Version - which published version served the run.

Open Run history on a pipeline to inspect any run node by node and see exactly how a prompt became an output.


Usage & insights

The Usage & insights view aggregates across your account: total runs, runs via API, tokens, credits used, and success rate over the last 30 days, plus a per-pipeline breakdown. Use it to watch spend and reliability at a glance. You can export run history for SOC 2, HIPAA, or an internal audit.


Requirements for API calls

For a pipeline to serve API traffic it must:

  • Be published (an unpublished pipeline returns 409).

  • Have at least one input node (an entry point to accept the request).

  • Have at least one output node (to return a result).

See the Pipeline API for the full request and response contract.

Last updated