Partner & Developer onboarding
Teams
How developers work in teams in your API Portal: the Admin, Read-Only, and Restricted roles, per-area access for teams, API keys, and billing, inviting teammates by email, domain auto-join, and switching teams.
A developer works inside a team in your API Portal. The team owns the subscriptions, the 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 the 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, pending invitations, and, where enabled, domain joining. |
| Subscriptions | The subscriptions this team owns. |
| Credits | The team's prepaid credit balance. Shown only when the team uses prepaid credits. |
The Credits tab appears only when the team is on a prepaid plan. See Billing and credits for what it 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 across teams, API keys, and billing. For people who own the team and manage other members. |
| Read-Only | Read-only access across all three areas. |
| Restricted | A mix set per area, from None to Full. |
When every area is set to 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. |
| API keys | See the subscriptions and their credentials. | See credentials, manage them, and create new subscriptions. |
| Billing | See billing and invoices. | See and manage billing and credits. |
None gives no access in that area. Creating a subscription needs Full API keys access. Managing credits, including prepaid top-ups, needs Full billing access.
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 starts an invitation.
- They enter the teammate's email address.
- They pick Admin, Read-Only, or Restricted, 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.
How does domain auto-join work?
When your portal enables team domains, a team can list email domains and turn on domain joining. A developer who signs in with an email on one of those domains joins the team automatically, without an invitation.
- A team must have at least one associated domain before domain joining can be turned on.
- Free email domains, such as the common consumer mail providers, are rejected and cannot be used.
- When a member invites a teammate whose email is on a new company domain, the portal offers to associate that domain with the team.
The domain controls appear only when the team-domains feature is enabled for your portal. You turn this feature on from the dashboard. See Teams and companies for the admin side and how company mode maps domains to identity routing.
How does a developer switch teams?
A developer can belong to several teams and switches between them with the team switcher. Changing the active team changes which subscriptions, credentials, and credits the developer sees. 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 runs member approval, a new member's permissions stay off until your team approves them. A member is shown as approved, pending, or rejected, and only an approved member can act on their access.
If your portal does not run member approval, a member is approved at once and their permissions apply immediately. Member approval is part of approval groups, which also gate subscription requests. See Requests and approvals for how your team approves members and requests.
Where to next
Billing and credits
What a paying developer sees: invoices through the Stripe customer portal, consumption, prepaid credit top-ups, and request logs.
Teams and companies (admin)
The dashboard side of the same teams: how you manage 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 and developer onboarding
The full journey your developers go through, from discovering an API to calling it in production.