Teams and ownership
Five roles, invitations that last seven days, and ownership that moves only by a transfer the new owner confirms with a passkey.
Roles
owner- The owning account alone. Every level, plus deleting the application. Never given by invitation.
admin- View, develop and admin levels: production, client secrets, the team, disabling and enabling.
developer- View and develop levels: sandbox configuration, webhooks, test identities, the consent register.
viewer- View level: the application and its sub-resources, read-only.
billing- View level, for the person who looks after billing. On an active production application owned by someone else, it also lets them add credits to the owner's balance in the developer console; they pay, so the receipt is in their name, and the owner is told. It never sets a budget: budgets are the owner's alone.
GET /v1/developer/applications/{applicationId}/team returns the members with their roles, the pending invitations, and callerRole — your own role, which is what the console uses to decide what to show you.
Invitations
POST …/invitations with { email, role, message? } sends an emailed link. The link works for seven days; POST …/invitations/{invitationId}/resend sends it again with a new link and the clock restarted, and the previous link stops working. DELETE …/invitations/{invitationId} withdraws it.
The invited person opens the link signed in. GET /v1/developer/application-invitations/{token} answers pending or already_member, or a refusal — not found, expired, or signed in as a different account from the one invited. POST /v1/developer/application-invitations/{token}/accept joins them with the invited role. An invitation whose role is not a collaborator role joins as viewer.
PATCH …/members/{memberId} with { role } changes a member's role; DELETE …/members/{memberId} removes them. Managing the team is the team.manage capability, which needs the admin level — so owner and admin.
Transferring ownership
Ownership does not move by invitation or by editing a role. A transfer is started by UnifyID staff; the new owner then sees it at GET /v1/developer/application-transfers and either POST …/{transferId}/accept — with a passkey — or POST …/{transferId}/decline. The current owner watches the same list.
What this does not do
- There is no self-service transfer. The start of a transfer is a staff action; only acceptance and refusal are yours.
- An invitation is to an email address, accepted by an account. The account that accepts must be signed in with that address; a link forwarded to somebody else is refused.
Verified against API commit 234dba22 on 2026-10-18. The routes, scopes, checklist, events and limits on these pages are read from that export, not typed.