Docs/Accounts/Teams

Teams

Share an account with colleagues without sharing a login — seats, roles, invites, the workspace switcher, and how usage is billed.

Teams let other people see and work with your account without you handing over your password. Each collaborator signs in as themselves, and what they can do is decided by the role you give them.

PlanTeam members
FreeNot included
StarterNot included
Pro3
Mega10

The vocabulary

Five words that appear throughout the dashboard, and are worth pinning down before anything else:

WorkspaceOne account's view of the dashboard — its keys, analytics, plan and tools
OwnerThe account holder. Holds the subscription, and every action that touches credentials or money
MemberSomeone invited into your workspace, as an admin or a viewer
Team accessThe workspaces you have been invited to, listed alongside your own
SeatOne slot for one member. Pending invites occupy one; you, as owner, do not

What sharing gets them

A collaborator sees your workspace — the API keys, the usage, the analytics, the plan. They do not get their own credits or their own allowance: it is your account, viewed by someone else.

That is the model to keep in mind. Teams are for visibility and operation, not for dividing an account into separate tenants. If you need genuinely separate access with independent revocation, that is a sub-key — a different tool for a different problem.

Roles

Three, and only two of them are ones you assign:

RoleCan
OwnerEverything, including keys, membership and billing. Exactly one, and it is you
AdminEverything a viewer can, plus manage the VerveKit tools and the AI Assistant
ViewerRead-only across keys, analytics and usage

Neither assignable role can manage keys. Rotating, scoping and creating sub-keys are owner-only, even for an admin — roles has the full matrix and the reasoning.

Seats

Your plan sets how many seats you have, and the number comes from the same published plan data the pricing page reads, so the meter in the dashboard and the table above never disagree.

Three rules govern the count:

Members and pending invites both consume a seat. An invite nobody has answered is a seat nobody is using.

You do not. The members panel counts you in its total; the seat meter does not.

Freeing a seat is immediate. Cancelling an invite, removing a member or a member leaving all return the seat at once, with nothing to wait for.

When the meter is full, the dashboard offers the upgrade — but check your pending invites first, because stale ones are the usual reason a small team runs out of room.

Inviting someone

Teams in the dashboard. Enter an email address, choose the role, send.

Two prerequisites, both of which reject the invite rather than queue it:

They must already have an APIVerve account, registered to that exact address. An invite to an address with no account behind it is refused — sign-up is free, so the fix is to have them sign up first.

Your own email must be verified. Every team action checks it: inviting, cancelling, re-roling and removing.

The form also refuses inviting yourself, inviting an existing member, and re-sending to the same person more than once in 24 hours.

Invites covers the whole flow, including what a re-send does to the previous link.

Working in someone else's workspace

Once you belong to more than one account, the switcher in the dashboard header moves you between them, and a context bar names the workspace you are in on every page.

Two things behave differently while you are viewing someone else's workspace, regardless of role:

Settings are always personal. Profile, notifications, password and two-factor stay attached to the account that owns them, so those controls are read-only in a workspace you do not own.

Key management stays with the owner. Rotating a key or creating a sub-key is refused for anyone else, admins included.

Workspaces covers the switcher, the pages that redirect, and which key a playground call actually bills to.

Billing and usage

Team billing is deliberately simple, which is most of the appeal:

One subscription covers everyone. Members do not need their own paid plans. You can bring in developers, contractors or partners without adding subscriptions.

Usage is shared. Calls made with the account's key count against the account's allowance and appear in the owner's analytics, whoever made them.

Only the owner manages money. Members visiting billing are told as much, and the plans page redirects there rather than offering an upgrade on someone else's card.

One nuance worth knowing before you assume every call in a shared workspace is on the owner: where a member can choose between the workspace's key and one of their own, the call bills to whichever key was picked. Being in a workspace does not by itself spend its credits — using its key does.

Managing your team

All of it lives on the Teams page.

Change a role by switching a member between admin and viewer. It applies immediately, to open sessions too, and needs no re-invite.

Remove a member to end their access at once and free the seat. They can be invited again later.

Cancel a pending invite to kill its link and free its seat. Once an invite has been accepted it is a membership, so removal is the action instead — the dashboard will tell you so rather than failing quietly.

Leave a workspace you were invited to, from the same page, with the same immediate effect from the other side.

On Mega, all of this is written to the audit history with who did it and when, which is what you want during an incident and what a compliance review asks for.

Offboarding properly

The one thing removal does not do is invalidate a key someone already copied. Ending dashboard access and ending a credential they hold are separate actions, and only the first is a click.

When someone leaves for good:

  1. Remove them from the team.
  2. Rotate anything they could have read — see key rotation.
  3. Revoke sub-keys issued for their work, which can be done individually without disturbing anything else.
  4. Check analytics afterwards for calls from an integration nobody owns any more.

Steps 2 and 3 are the ones people skip, and they are the ones that matter.

When to use teams, and when not to

Use a team when someone needs to see usage, debug a failing integration, or manage the tooling alongside you. Everyone signing in as themselves is what makes the audit history meaningful — a shared login can never tell you who did what.

Use a sub-key instead when what needs access is a system rather than a person — a client's server, a scheduled job, a partner integration. Those want a credential you can revoke on its own, not a seat in your dashboard.

Use neither for a customer of yours. Teams are for people inside your organisation; giving a customer a seat gives them your keys and a view of your billing.

Good habits

  • Start everyone as a viewer. Promotion takes five seconds; over-granting is only noticed later.
  • Audit the list periodically. Both your members and the workspaces you still have access to.
  • Pair seats with sub-keys. A seat is for looking at the account; a sub-key is for the code someone writes against it.
  • Keep pending invites short-lived. They are seats, and an invite unanswered for a month is not going to be answered.
  • Offboard on the day, not at the end of the quarter — and do the key work, not just the seat.

Next

Roles has the full permission breakdown. Invites covers sending and accepting, and workspaces covers switching between accounts.

Was this page helpful?

Last updated