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.
RoleDashboardAgentsBillingSettingsCompliance
ownerfullfullfullfullfull
adminfullfullvieweditfull
memberfullownnonenoneview
viewerviewviewnonenoneview
auditorviewviewviewnonefull + export
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.
  • 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 feature flag on your plan. They’re not available on free or starter tiers.

​
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.). Owner-only because misconfiguration can lock everyone out of the org.

​
Usage + costs

Operational metrics + cost rollups. The dashboard cut (/usage) is broader; the billing cut (/costs, /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.
You want to…Where to do it instead
Change your billing planStripe Customer Portal (POST /billing/portal-session) or contact support
Apply a credit, extend a trial, issue a credit noteEmail support@mnemom.ai
Apply a coupon mid-cycleStripe Customer Portal or support
Override a plan’s quota for one memberNot self-service — contact support
Impersonate another member to debugNot supported — use the audit log to see what they did, or ask them directly
Suspend a member’s account globallyNot supported — DELETE /v1/orgs/{org_id}/members/{user_id} removes them from this org only
See another org’s data, even if you own bothNot supported — each org is fully isolated
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.

​
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. Today: not self-service — contact support. Roadmap: ownership transfer endpoint, gated by 2FA reverify and email confirmation. 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.