Publishing a release

A release is one immutable, versioned widget.zip plus release notes and a snapshot of the marketplace listing. The app keeps one permanent client_id; releases are the executable code that moves through moderation.

Release states

Status	Meaning
draft	Editable and available for local preview/testing
queued	Submitted and waiting for a moderator
testing	A moderator has started review
approved	Runnable code. It may be locally activated or moderator-approved; only the latter can back a public app
rejected	Returned with a reason; editable and resubmittable
withdrawn	Removed from the queue by the developer; editable again

draft -> upload/validate -> save locally
   |                         |
   +-> submit -> queued -> testing -> approved by moderator
                         \-> rejected -> fix -> submit again
queued/testing -> withdraw -> withdrawn

Actions and endpoints

Action	Endpoint	Notes
Create	POST /admin/settings/widget/release/create	client_id, unique semantic version, optional release_notes
Edit	POST /admin/settings/widget/release/update	Editable states only
Upload	POST /admin/settings/widget/release/upload	Multipart; append _id before file. Stores the archive only when validation succeeds
Save (local activation)	POST /admin/settings/widget/release/activate	Private app only; makes the version runnable in the developer tenant without marketplace moderation
Submit	POST /admin/settings/widget/release/submit	Editable release → queued
Withdraw	POST /admin/settings/widget/release/withdraw	queued/testing → withdrawn
List	POST /admin/settings/widget/release/get-paging	Filter by client_id, status and paging
Read one	POST /admin/settings/widget/release/get-by-id	{ "_id": "..." }

Mutation endpoints require an active developer account and the Bito account owner. A suspended developer can still read owned release history.

What submission validates

Before a release enters the queue:

• an archive must be attached;
• its stored validation report must have ok: true;
• every language selected on the app must have a complete listing snapshot: name, pre-install description, privacy-policy URL, and either support URL or support email;
• no sibling release for the same app may already be queued or testing.

The selected app languages are authoritative. Filling the archive's languages while leaving one selected marketplace card incomplete is not enough.

Local testing is not publication

The version row's Save button (local activation) is the Bito equivalent of the private-first testing stage described in amoCRM's widget upload guide: the code runs in the owning account so you can validate it before moderation. It does not make the app public and it does not count as moderator approval.

Use local testing to verify:

• every declared mount surface in the real admin panel;
• install, uninstall and reinstall callbacks;
• consent text, permissions and declared network destinations;
• settings persistence and teardown;
• failure states when the remote service is unavailable.

What release approval changes

When a moderator approves a release:

1. the release becomes approved, with reviewer and time recorded;
2. the app's current version points to it;
3. the archive is extracted to the production asset origin;
4. the release becomes eligible to mount after tenant installation and per-release consent.

Release approval does not publish the marketplace card. Public visibility belongs to the independent card review. A card moderator refuses to publish a widget app if its current release is only locally activated or otherwise unmoderated.

Publishing updates

For an already public app:

1. update General info if the listing or permissions changed;
2. create a new semantic version;
3. upload, validate and preview it;
4. submit the release and wait for approval;
5. submit the changed card separately if General info changed.

Every newly approved version requires each installed tenant to consent again before the new code mounts. Plan even cosmetic releases with that user action in mind.

The overall moderation structure is deliberately similar to amoCRM's review stages, but Bito exposes card review and release review as separate state machines.