Distribution Targets
Push a saved bot version to many target bots, on this instance or on other instances.
Distribution Targets lets a content manager roll a saved version out to a list of remote bots. It is different from Distribute Version in Versions: that one clones content to a bot on the same instance, while Distribution Targets pushes a chosen version to target bots that can live on other Botario instances (e.g. one source bot distributed to many customer instances).
Open it from the Versions tab via Distribute → External.
Adding a target
Click Add target and provide:
- Name: A label of your choice, e.g. Customer PROD.
- Target bot URL: The full URL of the target bot, which must contain the bot path, e.g.
https://customer.botario.cloud/#/bots/6aac56e3cf5484b7eefdc342. The bot id is read from that URL. A URL without/bots/<id>is rejected. - API key: A key created on the target instance that authorizes access to that bot.
When saving, the target is checked right away: it must be reachable and accept the API key. Otherwise it is not saved and the reason is shown.
Testing targets
The server checks all targets every 20 seconds in the background and stores the result. The list shows the last known state right away, and changes are pushed to the open page live:
- State:
- Reachable: The instance is up and the API key can access the bot.
- No access: The instance is reachable but the API key can't access the bot (wrong scope/role, or the key is scoped to a different bot).
- Unreachable: The instance itself did not respond.
- Version:
- the target's app version (from
/api/health/version), used for the exact-match check below, and - the deployed version: The comment of the version last deployed to that target from here (or the deploy time if the version has no comment), or Not deployed. Use version comments like Release October to see at a glance which version a target runs.
- the target's app version (from
Deploying a version
Pick the saved version to push (listed with date and comment, newest first), then use Deploy to all, Deploy selected (when rows are checked), or the per-row deploy action. A confirmation lists each target with its outcome:
- Ready → Deploying → Deployed, or Failed with a reason (e.g. Permission denied, Version mismatch, Unreachable).
Deploying overwrites the target bot's content with the pushed version, the same way a restore or clone does. After a successful deploy, the target automatically starts creating embeddings for the imported knowledge base documents, so they don't have to be triggered manually.
Before importing, the target takes a backup of its current state. If the import fails on the target, that backup is restored automatically and the target returns to its state before the deploy. The backup is removed afterwards and does not appear in the target's version list. If the restore itself fails, the backup is kept as a version named Backup before failed import in the target's version list, so it can be restored from there.
Tick Distribute without knowledge base contents to leave each target's own knowledge base untouched — only scripts, flows, settings, and the rest are overwritten, while the target keeps its existing documents.
Exact version match
A target is only eligible for deployment when its app version exactly matches this instance's app version. Targets on a different version are shown as Version mismatch and skipped. A bundle exported on one platform version must not be imported into a bot running a different one.
Target API key permissions
The API key stored for each target (created on the target instance) must have:
- role Backup Manager (
version-manager), and - Read scope (to check the target) and Write scope (to receive the deployed version).
Restricting the key to the single target bot is recommended but not required. See API-Keys for how to create one.
Notes
- Connected targets are not part of the bot's version export. Exporting or distributing a version never carries a bot's target list to another bot.
- All actions here require the Version Manager role on this instance.