Bot tools
Botyard REST API endpoints for bot tools.
6 endpoints in this group. Every request authenticates with an API key; see the API reference for the other groups.
- Check Tool Permissions:
POST /v1/orgs/{org_id}/bots/{bot_slug}/tools/permission-check - List Bot Tools:
GET /v1/orgs/{org_id}/bots/{bot_slug}/tools - Assign Tools:
POST /v1/orgs/{org_id}/bots/{bot_slug}/tools - Unassign Tools:
DELETE /v1/orgs/{org_id}/bots/{bot_slug}/tools - Replace Tools:
PUT /v1/orgs/{org_id}/bots/{bot_slug}/tools - Retry Tool Sync:
POST /v1/orgs/{org_id}/bots/{bot_slug}/tools/retry-sync
Upsert Tool Domain Settings
Set the settings for a tool domain. Gated like ``POST/PUT/DELETE /tools``, since settings management goes hand in hand with tool assignment: the caller must also manage the bot (its owner, the API key that created it, or an org owner when it has no owner).
Check Tool Permissions
Which permissions this tool set requires, and which the bot lacks. **One call for the whole set.** Beyond the obvious cost saving over N calls, a single resolution makes the answer internally consistent: N calls could interleave with a concurrent grant and return a combination of statuses that no single moment ever produced, which a user would then act on as a snapshot. A ``POST`` because the tool-id set is a request body, not because it writes. **Nothing here grants, revokes or assigns anything** — it reports. Issuance stays in ``AuthzGrantService`` with its no-escalation, tenant-containment and audit guarantees, and ``grantable_by_caller`` is advisory: the service re-runs the identical ``covers`` check on the write, so a client that ignores this answer gains nothing. Gated on reading the bot's tools rather than on ``authz:permission.read``: the question is *"what do these tools need?"*, asked by whoever is looking at the tool picker. It discloses the bot's authority only as a per-requirement satisfied/missing flag, which is strictly less than the permissions surface already returns to a holder of that permission.