API & Data

Authentication

Three ways to authenticate: browser sessions with JWT, machine access with scoped API keys, and single sign-on with Google.

Data Integrity Webhooks

Choose your method

JWT Bearer

Human sessions. Log in for a short-lived access token plus a refresh token.
API keys

Machines & integrations. A long-lived key capped by granular scopes.
OAuth SSO

Sign in with Google — no separate password to manage.

API keys & scopes

For programmatic access, mint an API key. Every key is capped by the scopes you grant it, so an integration can only touch what you allow — regardless of who owns it.

curl -X POST "https://{slug}.muntri.com/api/api-keys" \
  -H "Authorization: Bearer <your-jwt>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "My Integration",
    "scopes": ["contacts.read", "opportunities.read", "leads.write"],
    "expires_at": "2027-01-01"
  }'

The full key is shown once at creation — store it securely. Then send it on every request:

Authorization: ApiKey mnt_live_...

Authorization: Bearer mnt_live_... is also accepted — useful for MCP clients and HTTP libraries that only support bearer auth.

Key properties

Property	Detail
Format	`mnt_live_` + random suffix
Storage	Hashed at rest — never retrievable after creation
Scopes	Capped to what you grant; enforced on every request
Expiry	Optional expiration date (never expires if unset)
IP allowlist	Optional, when linked to a Connected App
Last used	Tracked automatically

Scope model

Scopes are {resource}.{action} — for example contacts.read or opportunities.write. Actions are read, write and delete. A crm.{action} wildcard grants that action across every resource.

Scopes cover 38 resources across the whole platform — every CRM object, the revenue lifecycle (quotes, orders, contracts, invoices, renewals), the post-sale modules (customers, support, enablement, compensation, RFx), and the platform surfaces (workflows, agents, users, integrations, reports, admin). The full catalog with descriptions is on the Scopes page.

Enforcement is two-layered: a baseline gate derives the required scope from the request path and method (reads need {resource}.read, writes {resource}.write, deletes {resource}.delete) on every API-key request, and permissioned routes enforce their explicit scope on top. Keys created with the read-only preset can never write, anywhere.

Least privilege

Grant the narrowest scopes an integration needs. A reporting tool wants analytics.read and a few *.read scopes — not crm.write. You can always add more later.

JWT (browser sessions)

The web app authenticates with a short-lived access token and a longer-lived refresh token.

curl -X POST "https://{slug}.muntri.com/api/auth/login" \
  -H "Content-Type: application/json" \
  -d '{"email": "[email protected]", "password": "..."}'

{ "access_token": "eyJ...", "refresh_token": "eyJ...", "must_change_password": false }

Send the access token on each request, and refresh it when it expires:

Authorization: Bearer eyJ...

Token behaviour

Tokens carry a tenant claim scoped to your subdomain — a token for acme.muntri.com is rejected on beta.muntri.com.
Changing your password invalidates existing tokens.
Logging out revokes the token immediately.

Google SSO

Turn on single sign-on to let your team log in with Google — no separate Muntri password required. Sessions issued via SSO behave exactly like a password login, including the tenant scoping above.

sequenceDiagram
  participant U as User
  participant M as Muntri
  participant G as Google
  U->>M: Sign in with Google
  M->>G: Redirect to consent
  G-->>M: Verified identity
  M-->>U: Session (JWT) for your workspace

Admin-controlled

Whether SSO can create new accounts on first login is a workspace setting your admin controls — so access stays governed.

Impersonation

Workspace admins can act as another user in the same workspace to reproduce an issue or check what someone sees. Every impersonation is audited, and it can never cross into another tenant's data.