Skip to content
Echopoint Echopoint Docs

Versions & publishing

Editing a flow changes its working definition immediately. Publish takes a snapshot of that definition and freezes it as an immutable version — the version never changes afterwards, no matter how the flow evolves.

Publishing

Section titled “Publishing”

Press Publish on the flow canvas when the flow is in a state worth keeping: assertions green, structure validated. Each publish produces a new version with its own version-id.

Viewing and restoring versions

Section titled “Viewing and restoring versions”

The flow’s version list shows every published snapshot. From there you can:

  • View a version — inspect exactly what nodes, edges, outputs, and assertions it contained.
  • Restore a version — replace the current working definition with the snapshot. Restoring is how you roll back an edit that broke the flow.

Pinning a version at launch

Section titled “Pinning a version at launch”

By default, a launch runs the flow’s current definition. Passing a version-id pins the run to a published snapshot instead.

From the CLI:

Terminal window
echopoint flows run <flow-id> --version-id <version-id>

From the GitHub Action:

- uses: nanostack-dev/echopoint-cli@v1
  with:
    api-key: ${{ secrets.ECHOPOINT_API_KEY }}
    organization-id: ${{ secrets.ECHOPOINT_ORG_ID }}
    flow-id: <flow-id>
    version-id: <version-id>

Why pin in CI

Section titled “Why pin in CI”

An unpinned CI run executes whatever the flow looks like at that moment. If a teammate is mid-edit on the canvas — half the assertions moved, a node temporarily deleted — your pipeline runs that half-finished state.

Pinning removes the race:

  • Reproducible: the same version-id runs the same nodes, edges, and assertions every time. A red build means the API changed, not the test.
  • Edit safely: iterate on the canvas without touching what CI executes. When the new shape is ready, publish and bump the pinned version-id in your pipeline — an explicit, reviewable change.
  • Debuggable: when a pipeline run fails, you can open the exact version it executed instead of reconstructing what the flow looked like at the time.

The pattern mirrors dependency pinning: publish is the release, the version-id is the locked version your pipeline consumes.

Next steps

Section titled “Next steps”