Skip to main content
Mesh API organizes everything under a tenant hierarchy so teams can share billing, set usage limits, and control who can do what. You manage all of this from the Dashboard.

​
The hierarchy

A user can belong to several organizations and switches between them in the dashboard; GET /v1/orgs lists every membership. You can own only one organization at a time.

​
Roles

​
Organization roles

On top of a built-in role, an owner or admin can grant custom roles, named permission sets created under Settings → Roles. A custom role adds permissions; it never removes what the built-in role grants, and you can only grant authority you hold yourself.

​
Team roles

Organization owners and admins automatically have admin access to every team in the organization.

​
Inviting members

1

Send an invitation

An organization owner or admin invites a teammate by email from the Dashboard, choosing their role (admin, member, or viewer) and any custom roles and, optionally, a team to add them to.
2

The invitee accepts

The invited person receives an email with a link. After signing in with the invited email address, they accept the invitation to join the organization with the assigned role.
3

Manage pending invitations

Admins can view, resend, or revoke pending invitations from the Dashboard. Invitations expire automatically after 72 hours.

​
Usage limits & spend caps

Limits can be set at five scopes. Each scope supports the same set of controls: The five scopes: A request must satisfy every limit that applies to it — across the key, the member, the team, and the organization. If any one of them is exceeded, the request is rejected. Any scope left unset has no limit at that level.
Spend caps at the organization, team, and member levels are evaluated over a rolling 30-day window.

​
When a limit is hit

Rate-limit responses include a Retry-After header indicating how long to wait before retrying. If a member or organization spend cap is reached, contact your organization admin to raise it.

​
Managing orgs through the API

Org governance — invites, roles, teams, ownership — is a dashboard surface. Those endpoints authenticate a signed-in person and accept neither an rsk_ key nor a mak_ admin key, so there is no scripted equivalent. What automation can do: manage keys and limits with an admin key, and read usage, spend trend, and audit logs with an rsk_ key through the Usage & Monitoring API and /v1/audit-logs.

​
The /current model

Every org endpoint is scoped to /current — the org the caller is signed in to. There is no {org_id} path parameter anywhere in the API:
Because the target org comes from the session, acting on a stale one silently hits the wrong org rather than erroring. If you belong to more than one org, switch orgs in the dashboard before making changes.

​
Inviting people

Invite from Dashboard → Settings → People. Creating a member is creating an invitation: POST /v1/orgs/current/members, what that screen calls, returns an invitation record, and the person joins when they accept it. The invitee accepts through /v1/invitations — they can validate a token, list invitations addressed to them, and accept one.
You cannot assign owner through an invitation, and you cannot change someone into an owner with a role update — ownership moves only through POST /v1/orgs/current/transfer-ownership. Attempting either returns 422.

​
Shared billing

Every member of an org spends from one balance — the owner’s. There is no per-member wallet. A single member with an uncapped key can consume the entire organization’s credit.Per-member spend caps are the control for this, and they are unlimited by default. Set them deliberately; see Rate Limits & Spend Caps.
Settings → Usage (GET /v1/orgs/current/spend, and /spend/by-team per team) breaks spend down by member and team, which is the fastest way to find out where the balance went.

​
Pooled limits

Limits set at org, team, and member level combine with the key’s own limits, and the smallest applicable value wins. Raising a key’s limit does nothing if the team above it is lower. GET /v1/keys/{id}/limits shows the resolved result and which tier is binding — see Rate Limits & Spend Caps.

​
Org-wide settings

Owners and admins set org-wide policy under Settings. Each setting reaches keys differently:
  • Model access — an org-level allowed_models / blocked_models policy. A model must pass the org, team, member, and key policies together, and a block at any of them wins.
  • Data protection — the org’s default PII redaction policy. A key with its own pii_policy uses that instead, so {"enabled": false} on a key turns redaction off for that key.
  • Request bodies — the org’s default for keeping request and response bodies readable. A key’s own body_log_policy replaces it.
  • Data retention — zero data retention for the whole org. No key can override it, and turning on a key’s body_log_policy returns 422 while it is on.
  • API contract — the org’s default_api_version, copied onto keys created after you set it. Existing keys keep their version. See API Versioning.

​
Audit log

Every governance action in your org — key created, member invited, role changed, limit updated — is recorded in an append-only audit trail.
Audit reads are owner/admin-only, and an rsk_ key inherits the role of whoever owns it. GET /v1/audit-logs.csv returns the same filtered trail as a CSV download for compliance reviews.