Skip to main content

Managed Updates for Subscribers

You never push a new version to a subscriber. You offer it. The buyer decides (dec-086).

How an update reaches a buyer​

  1. You publish a new version of a managed listing. It must be a published, stable, non-yanked version.
  2. You offer one exact version to one subscribing workspace. The offer copies that version's metadata, so a later catalog change cannot alter what the buyer approves.
  3. The buyer sees the offer in their workspace and accepts or rejects it.
  4. Accepting applies the version in the same step.
  5. Rejecting leaves the buyer on the version they have.

An offer is an authenticated call to the marketplace API (POST /api/v1/managed-releases/offer with the listing SKU, the workspace and the version). Only the listing's publisher can make it. Neither SchemaBounce nor you can apply a version without the buyer's accept.

What an update changes​

Accepting changes only your content:

  • the SOUL,
  • the agent documents,
  • your builder rules,
  • the version provenance.

It never changes the buyer's own settings: their model, schedule, skills, custom rules and connections stay as they set them.

Rollback​

Rolling back means applying an earlier version the same way: an offer the buyer accepts. Published versions are immutable, so the earlier version is exactly what the buyer had before.

If you ship a bad version, yank it. Nobody new gets it and buyers already on it are unaffected. See Listing types and pricing.

Sealed listings​

A new version of a sealed listing does not reach buyers until it passes certification. See Open and sealed listings.

What the buyer sees​

The subscriber's view of a managed team and its updates is in Managed Services.