Version Pinning
How prices lock to a workflow version and what happens when creators publish new versions.
Developers running workflows through the API.
Overview#
Each workflow version has its own margin, hosted compute estimate, and displayed price. Wallet-funded runs use the version selected for that run. A bundle or supported legacy purchase creates a lasting version lock.
Bundles are locked to the version they were purchased with. They only draw when you run that exact version.
Some purchases are pinned to a workflow version. When access is not pinned, it follows the current active version.
How pinning works#
When a creator publishes, that version keeps its own displayed price.
A bundle applies to the version shown at purchase. Supported legacy access may also remain tied to its purchase version. Ordinary wallet-funded runs use the version selected for that run.
New purchases show the version they cover. Older access that follows the current version continues to do so unless the product offers an update choice.
When you trigger a run, the price comes from the version you selected. Wallet charges and bundle consumption use that version's displayed price.
Choosing a version#
Buyers can switch among available versions in the run UI. Each selection uses that version's current displayed price unless a matching bundle or supported legacy access record supplies a locked price.
Bundle runs remaining only appear when the selected version matches the bundle version.
API version resolution#
POST /runs pins every API-triggered run to one immutable workflow version. Two API callers can hit the same workflow id and end up on different graphs, in this order:
- Explicit
versionin the request body. The run executes that exact immutable graph. Owners can select any version; buyers can select the version their purchase pin covers. An unknown or forbiddenversionreturns 403 forbidden. - Pinned access. When
versionis omitted and the caller's access is pinned, the run executes that version. A newer active version does not silently upgrade the caller. - Current version. When
versionis omitted and the caller is not pinned, the run executes the current active version.
GET /workflows/{id} surfaces pinnedVersionId, activeVersionId, and updateAvailable so API integrators can detect drift without polling every run. Buyers who want to re-pin to the newest version can call POST /workflows/{id}/accept-update (requires workflow:write).
When creators change prices#
If a creator changes the price on a new version, existing matching bundles and supported legacy purchases retain their recorded version terms.
Wallet-funded buyers can choose the newer available version and pay its displayed price.
Unpublished versions#
An older version may remain available to customers whose bundle or purchase covers it. If it is unavailable, the UI shows an error and no run charge starts.
Special cases#
- Remix: A remixed workflow uses the version selected when the remix is published.
- Takedown: Access to an older version remains subject to product availability and platform policy.
What you see in Edgaze#
- Version selector with per-version displayed prices
- Matching bundle or legacy version highlighted where applicable
- Bundle runs remaining only when the selected version matches
- Error if an unpublished version's graph is missing
Related policies#
Was this useful?
Your response helps us improve the documentation.
Related documentation
How workflow runs are priced, funded, settled, and refunded. Step-by-step guides for buyers, creators, and developers.
How to open a workflow, fund a run, and what happens when it completes.
How the per-run price is built, what the creator earns, and what Edgaze keeps.