Submission and review lifecycle

Review is performed per app version. The current pipeline supports submission, Super Admin approval or rejection, publication, and immutable reviewed listing snapshots. It remains PARTIAL because other pre-enable Marketplace findings are unresolved.

Current flow

Developer registration → Draft App → Draft Version → Submit Version → submitted → Super Admin approve/reject → approved → Super Admin publish → published → merchant Owner/Admin install → active installation

Review decisions

A reviewer decides one of: approve, request changes, reject, reject permanently, and later publish or suspend.

• Request changes and reject return the version to you with a note. Edit the listing or manifest and submit the same version again.
• Reject permanently is final for that version: it cannot be resubmitted. Create a new version if you address the reasons.

Every decision and its note is kept in an append-only review history that you can read in the Developer Portal next to the version. There is no retired state.

If a migrated submitted version is marked legacy_unverified, its historical listing metadata is not accepted as review evidence. Super Admin may reject it, but may not approve or publish it. The owning developer must then provide a complete new listing snapshot, producing a new unreviewed draft that must be submitted and reviewed normally.

Submission contents

Provide accurate bilingual listing metadata, publisher identity, category and pricing metadata, support and privacy URLs where applicable, exact redirect URIs, least-privilege scope requests, webhook declarations, bilingual release notes, and a clear data/uninstall policy. Do not send secrets through listing or review fields.

Review authority

Super Admin can approve, reject, publish, and suspend through audited platform operations. Support is read-only. Developers manage their own drafts and submit versions but cannot approve or publish them. Merchant Owner/Admin installs a published version; merchant Staff does not.

Restricted capabilities

Scopes that belong to official first-party runtimes (segments:write_membership, notifications:write, themes:write_extensions, forms:manage_submissions, assets:manage_digital) cannot be requested by third-party app versions. customers:write_tags, orders:write_tags, categories:read and orders:read_items are public API capabilities. App types without a public runtime (embedded_app, admin_extension, theme_extension) cannot be selected; external OAuth apps (external_app) are the supported type.

Version and scope principles

Approval attaches to the exact reviewed version and its public listing snapshot. Publication is serialized and protects the active listing pointer from stale publication decisions. An installation is pinned to its installed version and granted scopes. Publishing a newer version does not silently upgrade existing installations, and a new scope is not silently granted. A changed manifest requires review and an explicit merchant grant.

Current limitations

Reviewed listings, suspension revocation, merchant consent, operational scope contracts and fenced delivery are implemented. Resource producers and bounded uninstall receipts are implemented; full environment acceptance remains pending. Marketplace stays disabled until the required pre-enable work is complete.