> ## 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.

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`

A limit write only reaches the provider when that seat is writable. Claude Enterprise seats always are. A Cursor seat is writable when both of these hold:

* It came from a Cursor **Enterprise** team you connected with limit management enabled. A Cursor **Teams**-plan connection has no per-user limits to write.
* It appears in exactly one connected Cursor team. A person in two teams has their spend summed for reporting, but nOps will not guess which team's limit to change.

A write against a read-only seat fails with an explanatory error rather than being silently skipped, so you can tell a refused write from an applied one. Claude Enterprise addresses seats by provider user ID; Cursor addresses them by email, because the Cursor Admin API joins members to spend on email.

## 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** pages in the [Developers](/developers) tab 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.

For the product behavior behind these endpoints, see the AI guides:

* [AI](/ai/introduction): what the AI area covers, and the plan and role requirements
* [Set up AI seat tracking](/ai/setup): connect providers and create a project
* [Wallets](/ai/wallets): allocation groups, group sync, and approvers
* [Budgets](/ai/budgets): group and per-seat planning targets
* [Requests](/ai/requests): the limit-request queue, decisions, and temporary approvals
* [Automated Rebalance](/ai/automated-rebalance): autonomy states, approval modes, and run history


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.