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`.
Authorization
BearerAuth Botyard API key — see /docs/authentication.
In: header
Path Parameters
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Pack versions to install, one per bot.
Response Body
application/json
curl -X POST "https://example.com/v1/orgs/string/packs/installs" \ -H "Content-Type: application/json" \ -d '{ "installs": [ { "bot_id": "string", "pack_version_id": "string" } ] }'{
"installs": [
{
"bot_pack_install_id": "string",
"plan": {
"bot_id": "string",
"pack_id": "string",
"pack_version_id": "string",
"status": "install",
"bot_pack_install_id": "string",
"support": {
"level": "full",
"unsupported": [
{
"reason": "string",
"kind": "soul"
}
]
},
"items": [
{
"action": "add",
"reason": "string",
"kind": "soul"
}
],
"connections": [
{
"pack_version_connection_id": "string",
"action": "add",
"reason": "string",
"kind": "mcp_catalog_entry",
"mcp_server_ids": [
"string"
],
"mcp_server_id": "string",
"missing_tools": [
"string"
],
"unsupported_tools": [
"string"
]
}
],
"recommended_model": {
"provider": "botyard",
"model": "string"
}
}
}
],
"setups": [
{
"bot_pack_install_id": "string",
"pack_version_connection_id": "string",
"bot_pack_connection_setup_id": "string",
"action": {
"kind": "setup_form",
"mcp_catalog_entry_id": "string",
"fields": [
"string"
]
},
"state": "needs_input"
}
]
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"error_code": "string",
"errors": [
{
"pointer": "string",
"detail": "string",
"type": "string"
}
],
"trace_id": "string"
}List Bot Pack Installs
Packs installed on each bot, with what each install added or adopted. Each install lists every connection in `connections`: pending, or bound with its health (`needs_reconnect` is fixed by `POST …/mcp-servers/connections/{id}/ reconnect`). `pending_connections` is the not-done subset; `POST …/packs/setups/resume` says what each asks. Composio authorisations bound to these bots are re-checked first, at most once per interval.
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.