Skip to main content
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: 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 tab for request/response schemas and examples.
  • See Authentication for how to pass your API key.
  • See Pagination for how to iterate list responses.
For the product behavior behind these endpoints, see the AI guides:
  • AI: what the AI area covers, and the plan and role requirements
  • Set up AI seat tracking: connect providers and create a project
  • Wallets: allocation groups, group sync, and approvers
  • Budgets: group and per-seat planning targets
  • Requests: the limit-request queue, decisions, and temporary approvals
  • Automated Rebalance: autonomy states, approval modes, and run history