> ## Documentation Index
> Fetch the complete documentation index at: https://help.nops.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Seat tracking

> Manage AI seat spend, limits, and automation through the public API.

# Seat tracking

The seat tracking API lets you manage AI seat spend and limits for your team. It supports Claude Enterprise and Cursor, with controls for spend limits, limit requests, automation policies, and analytics.

All seat tracking endpoints are available under `/v1/seat-tracking`.

## Project-keyed model

Seat tracking is organized around **projects**. Each project is backed by a budget and groups together:

* Enabled providers (Claude Enterprise, Cursor)
* Per-user seat spend and limits
* Group allocation and targets
* Limit requests and reviewer routing
* Automation policies and rebalance runs
* Spend history and projections

A project ID looks like `aisp_xxxxxxxx`. Use the project ID to call all other seat tracking endpoints. You can list projects with `GET /v1/seat-tracking/projects` and create one with `POST /v1/seat-tracking/projects`.

## Scopes

Seat tracking endpoints require one of two new API key scopes:

| Scope                 | Access                                                                                 |
| --------------------- | -------------------------------------------------------------------------------------- |
| `seat-tracking:read`  | Read projects, seats, limits, requests, automation, and analytics.                     |
| `seat-tracking:write` | Create or update projects, limits, requests, automation, and reviewer/notify settings. |

Write endpoints that change real provider state also require an `Idempotency-Key` header.

## Legacy budget-nested aliases

The original endpoints under `/v1/budgets/{id}/ai-seat-tracking` are still supported but deprecated. They now accept either `budgets:*` or `seat-tracking:*` scopes. Prefer the project-keyed endpoints for new integrations.

## User-specific usage endpoints

The internal dashboard routes `my-usage` and `my-usage-history` resolve the target user from the signed-in session. API keys and MCP callers use a synthesized service user, so the public API exposes explicit user paths instead:

* `GET /v1/seat-tracking/projects/{projectId}/seats/{userId}/usage`
* `GET /v1/seat-tracking/projects/{projectId}/seats/{userId}/usage-history`

Replace `{userId}` with the nOps user ID of the seat you want to inspect.

## Writes that hit real provider APIs

Some endpoints call the Claude Enterprise or Cursor admin APIs directly. Those writes are gated by an `mcpAccess: 'none'` flag and are not reachable through the MCP envelope, even with `mcp:write`:

* `PATCH /v1/seat-tracking/projects/{projectId}/seats/limits`
* `PATCH /v1/seat-tracking/projects/{projectId}/seats/limits/bulk`
* `POST /v1/seat-tracking/projects/{projectId}/automation/run`
* `POST /v1/seat-tracking/projects/{projectId}/automation/runs/{runId}/approve`
* `POST /v1/seat-tracking/projects/{projectId}/automation/runs/{runId}/undo`

Cursor limits are read-only. Only Claude Enterprise supports spend limit writes today.

## Rate limits

`POST /v1/seat-tracking/projects/{projectId}/automation/run` is limited to a daily quota per organization (default 50). Other write endpoints follow the standard public API rate limits.

## Next steps

* Browse the [API reference](/api-reference) for request/response schemas and examples.
* See [Authentication](/developers/authentication) for how to pass your API key.
* See [Pagination](/developers/pagination) for how to iterate list responses.