Skip to main content
A business account (the owner) can invite people into their business, assign them roles, and control exactly what each person can see and do — separate from the internal admin panel. This document covers the API and the authorization rules enforced server-side.

Contents


Authorization model

Every TeamController endpoint is one of four tiers: A user with no role assigned behaves as viewer — read-only across business features (transactions, deposits, payouts, wallets, etc.) and cannot manage members, roles, or settings. This is enforced two ways:
  1. acceptInvitation assigns the viewer role by default when an invite doesn’t specify one.
Verified authorization matrix (owner / permitted member / plain viewer / outsider):

Default roles & permissions

When a team is created, five default roles are seeded (the owner can rename, edit, delete, or add to them freely — changes are per-team only): Permissions are grouped for UI rendering — e.g. “Team Members” (team.members.view, team.members.invite, team.members.remove, team.members.roles.assign), “Transactions”, “Payouts”, “Billing & Plans”, etc. Fetch the full list + groups via GET /teams/{teamId}/permissions.

Team members on the wider API

When a team member signs in to the dashboard, API calls run in the context of the business account according to their role. Viewers can only send GET requests; other roles need the matching permission for each action. Routes that change the member’s own credentials (PIN, passkeys, profile) always run as that member. KYC belongs to the business, not the member. Once the owner passes KYC, members can use KYC-gated endpoints within their role.

Team API keys

Teams create X-Api-Key / X-Api-Secret pairs for server-to-server use. A key belongs to the team, authenticates as the owner (roles don’t apply to keys), and must have an IP whitelist. Keys are rejected (no_api_key) on endpoints that change sign-in credentials or delete the account. Key management is dashboard-only and gated by team.api-keys.view / .create / .revoke. See Authentication and IP Whitelisting.

API reference

Auth (used by the portal’s login/register)

POST /api/v1/auth/login (account_id + app_secret) is the deprecated legacy login; see Authentication.

Current user’s teams

Team info

Invitations

The link in the invitation email points to GET /team-invitations/{invitationId} on the API host — https://api.yativo.com in production and https://smtp.yativo.com on sandbox (test-api.yativo.com 404s this page). It is a signed web URL, not under /api and not on the dashboard SPA (app.yativo.com, which 404s that path). Override the origin with TEAM_INVITE_URL if needed. Opening it accepts the invitation immediately — no sign-in step, since the URL signature proves the invitee received the email — and shows a plain result page. If the invitee has no Yativo account yet, one is created for their invited email; they then sign in with an email one-time code. The page reports an invalid or tampered link, an invitation that no longer exists, or that the invitee is already a member. An invitee who already owns or belongs to another active team can’t join a second one.

Permissions catalog

Roles

Member role management

API keys (dashboard-only)