Skip to main content
A release is an immutable snapshot of the configuration Salesive delivers to your installs:
  • the webhook URL, signing secret and webhookTopics
  • the launch URL (appUrl)
  • the redirect URIs
  • the storefront extensions (embeds and blocks)
  • the dashboard extensions
  • the MCP server URL
  • the workflow actions and triggers your app declares
Versions are per app, start at 1 and are never reused. The snapshot cannot be rewritten after the release is created.
Development config (devConfig) is deliberately not part of a release. It is your own testing target, and a development install is never pinned to a release.

​
Why use a release

Editing your app’s fields changes what every install sees immediately. A release lets you freeze a working config, publish a change deliberately, send it to a small share of installs first, and go back to the previous config without editing anything by hand.

​
Create and publish

Create a draft from the current config, then publish it:
Publishing makes the release current, retires the previous release and writes the snapshot back onto the app, so consumers that do not read releases still serve exactly what you published. Active production installs are pinned to the release.

​
Stage a rollout

Publish below 100 to send the change to a share of installs first:
Installs are bucketed deterministically from a hash of the installation id, so 25 percent always selects the same quarter. Raising it to 50 percent adds the next quarter and leaves the first one where it is; nobody is reshuffled. A staged publish needs an earlier published release for the rest of the installs. The first release of an app cannot go out below 100 percent. Widen or narrow the current release later without creating a version:
rolloutPercent is required on this route, because an omitted value would silently do nothing.

​
Roll back

A rollback publishes the chosen release’s snapshot as a new version. The old release keeps its version and snapshot; nothing is rewritten. You cannot roll back to a draft, because it was never published, and you cannot roll back to the release that is already current.

​
What an install runs

  • A new or reactivated production install is pinned to the current release, or to the previous published release when its stable bucket falls outside a staged rollout.
  • A pinned install uses its release’s webhook URL, signing secret and topics, even after you edit the app’s fields.
  • A development install is never pinned and keeps using devConfig.
  • An install created before releases existed has no release and falls back to the app’s current fields.

​
Keep the response server side

A release response can include the webhook signing secret. The routes are owner only, require your merchant session and never accept an app token, but do not log the response or ship it to a browser you do not control.

​
Next steps

Release endpoints

Request and response shapes for every release route.

Webhooks

How the pinned URL, secret and topics are used on delivery.