Your app page

Public integrations are managed under Integration → My apps. The page is divided into General info, Versions, Statistics, Reviews and Keys so the marketplace card and executable widget releases can move through review independently.

You need an active developer account, and developer actions must be performed by the Bito account owner.

1. Create the app shell

In My apps press Custom integration, and in the Create integration dialog press + Create on the row you need:

Type	Choose it when
External integration	Your service calls the Integration API but does not execute JavaScript inside Bito
Integration with custom code	The app also ships a widget.zip that mounts inside Bito

Complete the initial form and press Save. Bito shows client_id, secret and api_key; the secret is shown this once only. Copy all three before closing the dialog.

The app is created uninstalled in your own account. To test it, open it from the Installed list on the Integration page and press Install — until then API calls fail with Integration is not installed and the widget does not mount.

2. Claim the permanent app code

Open the new app and choose its app code:

warehouse_helper

It must use lowercase Latin letters, digits and underscores, be 3–32 characters long, and start with a letter. Press Check availability before saving.

The code is permanent. Bito rejects codes owned by another developer and codes reserved for built-in integrations. It becomes part of the app's public identity, so there is no rename after it is claimed.

3. Complete General info

Field	What it controls
Category	Marketplace category
Redirect URL	HTTPS install/OAuth callback
Access revoke hook URL	HTTPS uninstall callback
Webhook URL	Default data-webhook destination
Iframe URL	Optional hosted settings page; separate from an in-page custom widget
Grant access	Integration API permission keys shown to the tenant before install
Monetization	Free, or Paid on my own site with a public pricing URL

An empty permission list means full Integration API access. Declare the narrowest list that works; a tenant sees and accepts exactly this contract.

4. Build the marketplace card

Select the languages you publish in and a default language. Every selected language has its own card:

• integration name and short name;
• description before installation;
• setup instructions after installation;
• 400×272 marketplace image and 108×108 installed logo;
• gallery images (1188×616);
• privacy-policy URL;
• support URL or support email.

The post-install text supports #SUBDOMAIN#, #ACCOUNT_ID# and #USER_ID#. Bito substitutes them when a tenant reads the installed card.

The app card has its own statuses:

Card status	Meaning
draft	Never submitted
pending	Under card review; the card is locked, but version work continues
approved	The reviewed card is public
changed	The public card was edited; the last approved card stays live until the update is reviewed

5. Create and test a version

Open Versions, create a semantic version such as 1.0.0, add release notes and upload widget.zip. Bito validates the archive immediately and shows every error inline.

While the app is still private, the version row's Save button activates it only in your developer tenant. Use Preview and then exercise every declared surface in the real Bito UI. This local activation is not moderation and cannot be used to publish the app.

The listing is edited on General info. When a version is created, the current listing is copied into an immutable release snapshot so later edits cannot change what a moderator reviewed.

6. Submit two review tracks

A public widget has two submissions:

1. Release review in Versions checks the exact archive and version.
2. Card review in General info checks the marketplace identity, listing, URLs, permissions and commercial information.

The tracks do not lock each other. The recommended first-publication order is:

Complete card -> create release -> upload -> validate -> save/test locally
-> submit release -> release approved -> submit card -> card approved -> public

You may submit the card while a release is being reviewed, but the moderator cannot publish a widget app whose current release has not been moderator-approved. An API-only app has no release requirement.

Worked example: a public stock widget

This example mirrors the journey used in the amoCRM public-widget guide, but uses Bito's fields and package contract.

1. Request developer access and create a Widget integration named “Warehouse Helper”.
2. Copy the credentials and claim warehouse_helper.
3. Set install and revoke URLs on https://integration.example.com, declare only the product and warehouse permissions the service needs, and add support/privacy links.
4. Complete Uzbek, Russian and English cards.
5. Create version 1.0.0, upload a valid widget.zip, and save it locally.
6. Test every declared surface, uninstall/reinstall, and verify callbacks and consent.
7. Submit 1.0.0 for release review. Fix and resubmit if rejected.
8. After the release is approved, submit the card. Once the card is approved, tenants can find the app, install it and consent to 1.0.0.

Read next: Publishing a release and Submit for review.