Skip to main content
This guide is for the owner or admin of a Mnemom organization. It explains the capabilities of those roles, the role matrix in full, and the deliberate boundaries — what this API surface does not do, and where to go when you need those things. If you’re a regular member, viewer, or auditor, the API reference marks the role each endpoint requires.

​
The roles

A Mnemom organization has five roles. Every endpoint under /v1/orgs/{org_id}/* is gated against one or more of them. Two notes worth pinning:
  • Only owners change roles. The owner can promote a member to admin or set anyone’s role; admins cannot. Ownership transfer is not an API operation — contact support if you need it.
  • Only owners remove owners. An admin can remove members, viewers, auditors, and other admins, but removing an owner returns 403. The last owner can’t be removed by anyone.
  • auditor is the read-only-with-billing-and-compliance role. Auditors can read invoices, costs, the audit log, and webhook health, but cannot mutate anything. They’re the SOC 2 / SOX / DORA review role.
The viewer and auditor roles require the RBAC capability on your account. If it isn’t enabled, assigning either role fails with a message pointing at Pricing.

​
Surfaces an org admin operates

​
Members + invitations

Invite, change roles, remove members, manage pending invitations.

​
API keys

Two surfaces:
  • Personal keys (/v1/api-keys) — billed to the user, owned by the user. Any member creates their own.
  • Org keys (/v1/orgs/{org_id}/api-keys) — billed to the org, created by owners + admins only.
The API Keys guide walks through the distinction in detail and covers rotation.

​
Webhooks

Configure webhook endpoints for org events; check delivery health; redeliver failures.

​
SSO (SAML)

Configure SAML SSO with your IdP (Okta, Azure AD, Google Workspace, etc.). Every domain in allowed_domains must be one your organization has proven it controls. Add it with POST /v1/domains and verify it by DNS TXT record with POST /v1/domains/{domain}/verify before saving the SSO config. PUT /v1/orgs/{org_id}/sso refuses:
  • an unverified domain — 403 sso_domain_unverified
  • a domain already bound to another organization’s SSO — 409 sso_domain_conflict (a domain belongs to at most one org)
  • a public email provider domain such as gmail.com — 400 sso_domain_public

​
Usage + costs

Operational metrics + cost rollups. The dashboard cut (/usage) is broader; the billing cut (/costs, /orgs/{org_id}/billing/summary) is restricted.

​
Billing portal

Invoice history, PDFs, payment methods, subscription management — all run through Stripe’s hosted Customer Portal.

​
Audit log

Compliance-shaped read of every authenticated write made against the org’s API surface.

​
Safe House + alignment

Org-level posture for content-filter and alignment policy. Member configuration delegated to per-agent cards.

​
Conscience values

Org-level value declarations that propagate down to agent alignment cards.

​
What the API deliberately does not do

These capabilities exist in Mnemom but are not exposed to org admins via the API. This is by design and matches the convention used by Stripe, GitHub, and Cloudflare for similar reasons. The pattern: revenue-affecting changes go through a human at Mnemom, audit-affecting changes go through the audit log surface, cross-tenant operations don’t exist.

​
Acquiring the role

The user who creates an org becomes its owner. Owners can promote any member to admin via PATCH /v1/orgs/{org_id}/members/{user_id} with {"role": "admin"}. There is no self-service request-to-be-admin flow — escalation goes through the existing owner. A newly created org does not inherit any invite-gated product access (e.g. Mnemom Agent) you hold personally — that access is granted per account, and a brand-new shared org starts with none. Check GET /v1/code/entitlement?org_id={org_id} before relying on it there; if it’s not enabled, ask your Mnemom contact for an org-scoped invitation.

​
Common tasks

Onboard a new admin. Invite via POST /v1/orgs/{org_id}/invitations with role: "admin". They accept via the link in the invitation email. Once accepted, they have admin permissions immediately. Rotate a compromised key. Either personal (POST /v1/api-keys/{key_id}/rotate) or org-level (POST /v1/orgs/{org_id}/api-keys/{key_id}/rotate). The new key is returned in the response — capture it and update your deployment. The old key is revoked atomically; no grace period. See API Keys guide. Investigate a suspicious event. GET /v1/orgs/{org_id}/audit-log?limit=200 for the request log; cross-reference with webhook delivery log if external systems were notified. Hand off ownership when an admin leaves. Not self-service — contact support. Delegate management of one team without granting org-wide admin. Use the Team Admin role: POST /v1/teams/:team_id/admins with the target user’s user_id, or use the dashboard’s Roster tab on the team detail page. The grant covers that team’s templates, posture assignment, and roster — nothing else. Org admins still implicitly act as team admins for every team, so this is purely additive scoping. View invoices for accounting. POST /v1/orgs/{org_id}/billing/portal-session returns a one-time Stripe URL; the customer admin clicks through, downloads PDFs, sees payment status, updates the card if needed.

​
Security posture

  • All endpoints under /v1/orgs/{org_id}/* enforce membership in {org_id} plus the role gate documented per-endpoint. A caller from org-A with a valid token cannot access any resource under org-B.
  • API keys carry the role of the user who created them, scoped to the org they were created in. Personal keys cannot reach /v1/orgs/{org_id}/* paths for orgs the user doesn’t belong to.
  • All authenticated writes against your org’s API surface are logged in GET /v1/orgs/{org_id}/audit-log. Mnemom-staff actions on your account (such as a support engineer’s response to an open ticket) are not exposed in the customer audit log — if you need an account-level action attested for a compliance review, request a support letter.