`POST /installations/{id}/permissions` — approve some of the permissions the App declares that this installation does not hold yet (ADR-0079).
/installations/{id}/permissionsThe body is an install's: (scope, target) pairs, bounded the same way.
Only the installing team, acting as it, approves.
Path Parameters
Installation id (inst-…)
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
POST /apps/{id}/installations body.
⚠️ There is no team_id field, and adding one would reopen a check this
design removes. The installing team is auth.acting_team_id, which the
extractor has already validated is one of the caller's own teams
(extractor.rs:63-66) — so there is no field in which to name somebody
else's team, and no membership check to forget. export/logic.rs:56-62 is
the shipped precedent for reading the acting team this way.
Response Body
application/json
curl -X POST "https://example.com/installations/string/permissions" \ -H "Content-Type: application/json" \ -d '{}'{ "app_id": "string", "created_at": "string", "id": "string", "installed_by": "string", "pending_permissions": [ "string" ], "permissions": [ { "grant_id": "string", "scope": "string", "target": "string" } ], "team_id": "string"}`GET /installations` — every installation held by a team the caller belongs to (ADR-0050 §6). GET
**No team parameter, deliberately.** The set is `auth.team_ids`, so a caller cannot name a team they are not on — the bound is the permission scope rather than an argument to be validated. A caller on two teams gets the union of both. One synthetic page, like every list on this surface: the cost scales with the caller's team count rather than the org's install count, because there is no per-row join.
Investigation_create POST
Next Page