Submit for review

Submit only after the integration works end to end in your developer tenant. A public widget has two independent submissions; an API-only integration has only the app-card submission.

Before submitting

• The app code is claimed and permanent.
• Every selected marketplace language has a name, pre-install description, privacy policy, and support URL or email.
• Install, revoke and webhook URLs are public HTTPS endpoints and have been exercised.
• required_permissions is the narrowest list that works.
• The exact widget.zip attached to the release passes validation.
• The release was previewed or saved locally and tested on every declared surface.
• Uninstall/reinstall, error states and consent were tested.
• Release notes explain the behavior changed in this version.

amoCRM's official moderation guidance asks developers to provide a reproducible test case and any required test access. Follow the same operational discipline for Bito: make the moderator's path short, deterministic and free of production customer data. Never put long-lived secrets in the archive or public listing.

1. Submit the release

In My apps → app → Versions, open the intended version and press Submit for review.

POST /admin/settings/widget/release/submit
Authorization: Bearer <Bito session token>
Content-Type: application/json

{ "_id": "<release_id>" }

The release moves from an editable state to queued, then to testing when a moderator picks it up. You can withdraw it while it is queued or being tested.

2. Submit the app card

In General info, save all changes and press Submit for review.

POST /admin/settings/integration/publish
Authorization: Bearer <Bito session token>
Content-Type: application/json

{ "_id": "<integration_id>" }

The card moves to pending and is locked until it is approved, rejected or withdrawn. Version work remains available because the review tracks are separate.

For a first public widget, get the release moderator-approved before final card approval. Bito will not publish a card that points at a locally activated or unmoderated release.

What moderators inspect

The review follows the same practical layers described in amoCRM's public-integration requirements and moderation flow, applied to Bito's contracts. While a release is testing, the moderator works through three stages in strict order — each opens only after the previous one passed, and approval requires all three:

#	Stage	What is checked
1	Code check	Validation, assets and manifest pass; the static scan has no blockers; declared surfaces and permissions match what the code calls.
2	Listing check	Name, descriptions and setup instructions exist in every declared language; the privacy policy and support links resolve.
3	Usability test	Installed on a sandbox account: every declared surface opens and works, and uninstall runs cleanly.

Bito itself blocks the first stage: a release that failed validation, hit an asset-extraction error, or has a static-scan blocker cannot pass the Code check.

The static code scan

The .js and .html files in the uploaded archive are scanned line by line, and the findings are shown to the moderator next to the source.

Rule	Severity	What it finds
eval	Blocker	eval(...) — evaluating a string as code
new-function	Blocker	new Function(...) — building code from a string at runtime
string-timer	Blocker	Passing a string to setTimeout/setInterval
plain-http	Blocker	Calling a host over http:// (except localhost)
ip-literal	Blocker	Calling a host by IP address instead of a domain
remote-import	Blocker	import('https://...') — loading code from a remote URL
token-access	Review	getAccessToken() — check where the token is sent
storage-access	Review	document.cookie, localStorage, sessionStorage
inner-html	Review	.innerHTML = — tenant data must not land in markup unescaped
post-message-any	Review	postMessage(..., '*')
undeclared-origin	Review	An https:///wss:// origin the code calls but bito.network.connect_origins does not declare

A single blocker closes the first stage — fix the release and resubmit it with a new archive. Review findings do not stop anything, but the moderator reads them. The scan matches line patterns and does not understand the code, so the moderator still reads the source.

Decision log

Bito keeps a moderation log: on a release — review started, each stage passed (with the text of what was checked), approval and rejection; on a card — approval and rejection. Every entry carries the moderator's name and the time. The log is append-only. The rejection reason is shown to you on the release or card. When a release re-enters testing, the stages start over from zero.

Approval is not inferred from a successful upload or build. It is a separate human decision recorded on the card or release.