Contents
- Architecture
- Authorization model
- Default roles & permissions
- Team members on the wider API
- Team API keys
- API reference
Authorization model
EveryTeamController 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:
acceptInvitationassigns theviewerrole by default when an invite doesn’t specify one.
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 sendGET 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 createX-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.

