Skip to main content

Authentication

These routes are for the app owner’s merchant session, never an app_ token:
Every route checks that the app belongs to the signed-in developer. Responses can include the webhook signing secret, so keep them server side.

The release object

List releases

Newest version first. currentRelease is the published release installs are being pinned to, or null when the app has never published one.

Create a draft

Snapshots the app’s current delivery config into a new draft version. notes is optional, up to 2000 characters. Returns 201 with the release object. A release freezes webhookUrl, webhookSecret, webhookTopics, appUrl, redirectUris, extensions, dashboardExtensions, mcpServerUrl and workflow. Development config (devConfig) is not part of a release.

Publish a release

rolloutPercent is a whole number from 0 to 100 and defaults to 100. Publishing makes the release current, retires the previous release, writes the snapshot back onto the app and pins active production installs.
A publish below 100 needs an earlier published release for the rest of the installs. Assignment is deterministic: the same installation id always falls in the same bucket, so raising the percentage later adds installs and never reshuffles them.

Roll back

Publishes the chosen release’s snapshot as a new version. The old release keeps its version and snapshot; nothing is rewritten. The response is the publish response plus rolledBackFrom, the release you rolled back to. You cannot roll back to a draft, because it was never published, or to the release that is already current.

Change the rollout

Widen or narrow the current release without creating a version. rolloutPercent is required here, because an omitted value would silently do nothing. Returns the release and the assignment counts. This is the route to move the rest of the installs later.

Errors

Next steps

Releases guide

When to create, publish and roll back.

Webhooks

How a pinned release is used on delivery.