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

Each user belongs to one organization at a time. To join a different organization, you leave your current one when accepting the new invitation.

Roles

Organization roles

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 or member) 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 four scopes. Each scope supports the same set of controls: The four 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 management uses a user JWT — your dashboard session token — not an rsk_ key.

The /current model

Every org endpoint is scoped to /current — the org identified by your session token. There is no {org_id} path parameter anywhere in the API:
Because the target org comes from your token, a stale token silently acts on the wrong org rather than erroring. If you belong to more than one org, re-authenticate after switching rather than reusing a cached token.

Inviting people

Creating a member is creating an invitation — POST /v1/orgs/current/members 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.
GET /v1/orgs/current/spend breaks spend down by member, 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.

Audit log

Every governance action in your org — key created, member invited, role changed, limit updated — is recorded in an append-only audit trail.
GET /v1/audit-logs.csv returns the same filtered trail as a CSV download for compliance reviews.