Skip to main content

Versions and Install Links

This is where app development gets real.

The Versions page is where you edit the manifest, validate it, publish it, and decide how someone should install it.

Draft versus published

The split is simple and important.

  • Draft is where you edit
  • Published is what normal installs follow

That separation lets you keep active installs stable while you work on the next version.

What you edit in a version

In practice, version work includes:

  • manifest JSON
  • webhook subscription URL
  • webhook event selection
  • validation review

The portal also syncs external endpoint fields into the manifest, so version editing is not just one raw JSON box with no guardrails around it.

Validate before you publish

Validation is there to catch bad assumptions before you push a version live.

Use it to check:

  • whether the manifest is structurally valid
  • whether the policy value makes sense
  • whether publish would fail for an obvious reason

If validation is noisy, fix the draft instead of trying to publish through it.

When to publish

Publish when the version is stable enough for real installs to follow it.

Do not publish just because the draft technically validates. Validation is the floor, not the release decision.

The portal can generate install links for both published and draft work.

That distinction matters:

  • published installs use the live published channel
  • draft installs can point to a specific draft version for preview work

That makes draft install links useful for testing without pretending the version is ready for broad use.

Use draft installs carefully

Draft installs are for controlled testing.

They are useful when you want to:

  • test a new version in one workspace
  • confirm manifest behavior before publishing
  • let a small group review an app safely

They are not a replacement for publishing discipline.

A practical release pattern

  1. create a new draft version
  2. update the manifest and endpoint settings
  3. validate until the draft is clean
  4. test through a draft install if needed
  5. publish when the version is ready

Next reads