Uninstall Packs
Uninstall packs: every one, or none. Returns what was done (200, not 204). The pack's skills, tools and secret links go; its soul, settings and avatar are put back. Anything the bot had before the install, or that someone changed since, is kept and reported. Org MCP servers and vault entries are never touched. Errors point into `uninstalls[i]`, in query order.
Authorization
BearerAuth Botyard API key — see /docs/authentication.
In: header
Path Parameters
Query Parameters
Installs to remove, each at most once.
Response Body
application/json
curl -X DELETE "https://example.com/v1/orgs/string/packs/installs?bot_pack_install_ids=497f6eca-6276-4993-bfeb-53cbbbba6f08"{
"uninstalls": [
{
"bot_pack_install_id": "string",
"bot_id": "string",
"pack_id": "string",
"pack_version_id": "string",
"items": [
{
"bot_pack_item_id": "string",
"reason": "string",
"kind": "skill",
"action": "remove",
"skill_id": "string"
}
],
"already_removed": [
{
"bot_pack_item_id": "string",
"kind": "skill"
}
]
}
]
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"error_code": "string",
"errors": [
{
"pointer": "string",
"detail": "string",
"type": "string"
}
],
"trace_id": "string"
}Install Packs
Install pack versions on bots: every one, or none. Only a bot's owner may install a pack on it, even on a bot open to every member; otherwise the whole batch is a 403 and nothing is written. Re-installing the version a bot already runs is `unchanged`. What the install could not bind by itself is reported in `setups`, each with the action it asks next (run it, a connect link, a secret to store, a server to choose); carry them on with the setups routes. **Turned off for now:** installing onto an existing bot would replace its soul, so every batch is refused with a 409 `pack_install_existing_bot_disabled` and nothing is written, until multi-pack installs and soul merging land. Create a bot from the pack instead (`POST /bots/from-pack`). Uninstalling, binding connections and the setup steps still work. A `create` connection choice connects a new account after the install commits, as `POST /bots/from-pack` does; it needs `mcp_server.create`.
Preview Pack Connections
What each connection of these pack versions needs, before any bot exists (P3.4). Per connection: what connecting a new account takes (`setup`, decided by the same rule as the setup engine), whether a new server is metered, and the org's existing servers from that catalogue entry that you may see, each with its account, owner, access, the bots using it and its health. Bots you may not read are only counted. A read: nothing is written and no vendor is called. POST because it is a by-id read with a JSON body; `GET /packs/versions` reads the same ids' contents.