Skip to main content
An organization API key (reinx_org_live_…) is how a backend or an orchestrator agent manages a fleet: create agents, set their budgets, pause them, read their activity. It is a machine principal — no human identity behind it — deliberately separated from the agent keys that spend. An orchestrator provisions and supervises; the agents it creates do the spending. Neither can do the other’s job.

​
Mint a key

Settings → Organization → API Keys in the dashboard. Minting requires step-up re-verification, and you choose three things at that moment:
  • Scopes — what kinds of action the key may take.
  • Binding — which container (the organization, one project, or one team) it may act inside.
  • Daily create limit — how many agents/projects/teams this key may create per UTC day. Defaults to 100; settable anywhere from 1 to 1,000. Lower it for a key that should only ever provision a handful of agents — it is the cheapest blast-radius control you have.
All three are fixed for the key’s life, and rotation preserves them. Changing any means minting a new key.
The key is shown once. Store it in your backend’s secret manager, never in source control and never in an LLM’s prompt or memory. Revoke and re-mint if it leaks — revocation is immediate, because the key is verified against the database on every request with no cache.

​
First call

Returns the agents inside your key’s binding. If you minted with only the default scopes, this works and writes do not — see scopes.

​
Two ways to drive it

Same credential, same scopes, same binding, same contracts. Pick whichever fits how your orchestrator is built; you can use both.
Where the REST shapes are documented. The agent endpoints have reference pages here (Agents, Transactions). The project and team management endpoints (projects:write / teams:write) do not have standalone reference pages yet — the MCP management band tools proxy them, so its request/response contracts (required idempotencyKey, the version loop, the full-replacement budget and approval-rules shapes) are the authoritative reference for the management behavior on both transports until the dedicated REST pages land. One caveat for direct REST callers: the MCP tool schemas are a deliberately constrained subset of the create fields — POST /v1/projects and POST /v1/teams also accept optional presentation fields (color, a tile logo) that the tools don’t surface. A REST integration may send those; an MCP orchestrator creates with name + description only.
The limits are not the same — size concurrency per transport. MCP has its own, lower plan ceiling (60/600/3,000 per min for Free/Pro/Enterprise, versus 100/1,000/5,000 on REST), and management writes add 20/min per key and 40/min per org on top. An MCP management write then makes the proxied REST call, so it can also meet that route’s own cap. Sizing an MCP workload from REST numbers will produce unexpected 429s.

​
Creating an agent

The one call with a contract worth reading before you write it:
idempotencyKey is required for machine callers and must be generated and persisted by you, before the call. The response carries the new agent’s one-time API key, so a lost response without a saved idempotency key means an orphaned agent and an unrecoverable credential. With one, you simply replay the same key and payload and get the committed agent back. Full field list and error handling: Agents.

​
Reconfiguring

All reconfiguring writes are optimistically concurrent: read to get the current version, modify, write it back with that version, and on a stale token re-read and retry — never blind-write.
A stale token does not return one code — it returns three, by endpoint. Branch on all of them or you will miss conflicts on four of the five:
And the two write shapes are different:
  • Agent budget policy is a partial patch — an omitted field is left unchanged. Clear a spend ceiling by sending it explicitly as null.
  • Project and team budget PUTs are structured full replacements: send capCents, the complete child array (teams for a project, agents for a team), and version. A missing child is rejected 422 — you cannot drop one to leave it alone. Clearing a cap means capCents: null, not omission.
  • Approval-rule PUTs replace the whole rules array. Omitting an entry deletes that rule; there is no per-field merge.
Getting these backwards leaves a spending ceiling in force when you believed you removed it, or silently drops a child allocation.

Scopes and bindings

The six grantable scopes, the binding matrix, and why some reads need a write scope.

Limits and boundaries

What an organization key can never do — and why your key got a 403.

Management band

The 21 MCP tools, with the create and archive contracts in full.

Errors

Every organization-key error code and what to do about it.