API
Roster exposes REST endpoints under /api/v1. Use REST for:
- external integrations
- automation
- SDK generation
- OpenAPI-style clients
The CLI is MCP-first and should normally call /mcp. Use REST deliberately
when an integration needs the HTTP resource surface.
Base Path
Section titled “Base Path”/api/v1Authorization Model
Section titled “Authorization Model”API keys are owned by platform identities. A key never has more access than its owner, granted scopes, and resource authorization allow.
Admin identities operate globally. Project owners operate only on projects where they are assigned as owners.
Endpoint Groups
Section titled “Endpoint Groups”| Group | Paths |
|---|---|
| Projects | /api/v1/projects, /api/v1/projects/:id |
| Participants | /api/v1/participants, /api/v1/participants/:id, /api/v1/participants/:id/members |
| Directory Records | /api/v1/directory-records |
| Labels | /api/v1/labels, /api/v1/labels/:id |
| Delegations | /api/v1/delegations, /api/v1/delegations/:id |
| Resolve | /api/v1/resolve, /api/v1/resolve-requests, /api/v1/resolve-requests/:id |
Start with Authentication for scopes, use API Errors for strict Problem Details error handling, then use REST Endpoints for implemented behavior. For CRUD and resolve access decisions, see Authorization.
Administration Endpoint Status
Section titled “Administration Endpoint Status”The REST API does not currently expose endpoint groups for platform administration resources such as team members, AI agents, service accounts, API keys, audit events, model runs, provider connectors, or settings. Manage those resources from the Platform web UI unless your deployment adds a custom integration layer.