Partner & Developer onboarding
Teams
How developers work in teams in your API Portal: the Admin, Read Only, and Restricted roles, per-area access to team members, API keys, and billing, inviting teammates, how domain joining really works, and switching teams.
A developer works inside a team in your API Portal. The team owns the subscriptions, their credentials, and any prepaid credits, and each member holds a role that sets what they can see and change. This page describes what your developers experience when they run teams in your portal.
What is a team in your API Portal?
A team is the group a developer works in, and every subscription belongs to a team. A team holds its members, its subscriptions, the credentials on those subscriptions, and a prepaid credit balance where a plan uses one. A single developer still works inside a team.
A developer opens a team to reach its detail view, which carries the team name and a set of tabs.
| Tab | What it shows |
|---|---|
| Details | The team name, the members and pending invitations, and, where your portal turns it on, domain joining and the team's domains. |
| Subscriptions | The subscriptions this team owns. |
| Credits | The team's prepaid credit balance. Shown once the team has a subscription on a prepaid plan. |
See Billing and credits for what the Credits tab shows.
What roles can a team member have?
A member holds one of three roles: Admin, Read Only, or Restricted. The role is a label for the access set across three areas. The portal derives the label from those areas, so the role and the access stay in step.
| Role | What it grants |
|---|---|
| Admin | Full access to the team's members, API keys, and billing. For people who own the team and manage other members. |
| Read Only | Read Only access to all three areas. |
| Restricted | A mix set per area, from None to Full. |
When every area is Full, the role reads as Admin. When every area is Read Only, it reads as Read Only. Any other combination reads as Restricted.
What does each access area control?
Access is split into three areas, each set to None, Read Only, or Full. The combination decides what a member can do.
| Area | Read Only grants | Full grants |
|---|---|---|
| Teams | See the team's members. | See members, invite teammates, manage members, and edit the team, including its domains. |
| API keys | See the subscriptions' credentials, masked. | Create subscriptions, and create, regenerate, or rotate credentials. |
| Billing | See the Billing tab and invoices. | Manage billing and top up credits. |
None gives no access in that area. Some actions need more than one area:
| Action | Who can do it |
|---|---|
| Subscribe to a plan | Members with Full API keys access. |
| Cancel a subscription | Members with Full API keys and Full billing access. |
| Change plan or upgrade a subscription | The subscription's owner, or members with Full API keys and Full billing access. |
A member who owns any of the team's subscriptions can't be removed from the team until those subscriptions have a new owner. Remove from team offers Migrate to pick a new owner from the team. A subscription billed through Stripe can't be migrated this way.
How does a developer invite a teammate?
A member with Full team access invites a teammate by email. They choose a role, or set each area by hand, and send the invitation. The teammate receives a link, signs in or signs up, and joins the team.
- A member with Full team access opens the team and clicks Invite a new member.
- They enter the teammate's email address.
- They pick Invite as Admin, Invite as Read-Only Access, or Invite as Restricted Access, or set the teams, API keys, and billing areas one by one.
- They send the invitation. The teammate appears as pending until they accept.
A member cannot grant access above their own level. If a member has Read Only billing access, they cannot give a teammate Full billing access. The invitation form caps each area at the inviter's own level.
Every invitation also adds the invitee's email domain to the team's domains, including free email domains. See How does domain joining work? for why that matters.
How does domain joining work?
Nothing joins a team automatically. When your portal turns on team domain joining and a team enables it, a new developer who signs up with an email on one of the team's domains is offered that team once, during sign-up. Join team makes them an Admin.
- The offer appears in the Join your team step of sign-up, which lists every matching team. Developers who already have an account are not offered teams by domain.
- A developer who joins this way gets Admin: Full access to the team's members, API keys, and billing, including the credentials on its subscriptions.
- A developer creating their own team at sign-up can let their colleagues join by domain with Allow users from the same email domain to join your team?. It starts selected, and free email domains are never added this way.
- Your portal can hide the option to create a new team when sign-up offers a matching one.
When your portal turns domain joining on, the team's Details tab shows Enable domain joining and the Team domains list. Members with Full team access can switch it and remove a domain. The team's domains grow in three ways: from sign-up, from every invitation sent from the API Portal, and from your team in the dashboard.
How does a developer switch teams?
A developer can belong to several teams and switches between them with Change team, which lists the Available teams. Changing the active team changes which subscriptions, credentials, and credits the developer sees, and the portal confirms the change.
The active team is the one a developer is currently working in. Access is per team, so the same developer can be an Admin in one team and Restricted in another. The role that applies is the role they hold in the active team.
When do a member's permissions take effect?
When your portal requires registration approval, a new developer can't act in any team until your team approves their account. The team's member list shows whether each member is active, pending approval, or rejected.
If your portal does not require registration approval, accounts are approved at once and permissions apply immediately. Registration approval is set in Portal details in the dashboard; see Requests and approvals for where you approve new accounts.
Where to next
Billing and credits
What a paying developer sees: invoices, consumption, prepaid credit top-ups, and request logs.
Teams and companies (admin)
The dashboard side of the same teams: members, domain joining, company mode, and credits.
Subscribing to a plan
How a developer subscribes to one of your plans, and what each subscription status means.
Partner & Developer onboarding
The full journey your developers go through, from discovering an API to calling it in production.