Team

Invite colleagues into the workspace, understand what each role can do, and keep every change attributable to a person.

After this page you can bring a colleague into the workspace, know what they will be able to do before you send the invitation, and keep the activity log worth reading. A workspace belongs to a business, not to a login.

Team in the console lists the people who run the workspace — its owner and its admins — with each one's role, and is where invitations are sent, resent and withdrawn. It also shows how many seats your plan leaves; how many that is depends on your plan — see pricing.

Who can administer a tracking workspace

Everything behind the publisher console asks one question of whoever is signed in: do they hold an owner or admin seat on this workspace, or on any workspace above it? Anything else is refused.

Role	In the publisher console
Owner	Full access, including the plan, the card, the wallet and the team. Only the owner invites an admin, and only the owner takes an admin seat back, locks it or removes it. A workspace has exactly one owner.
Admin	Full access to day-to-day operation: campaigns, routing plans, buyers, targets, sub-publishers, numbers, webhooks and API keys. An admin cannot change billing or the plan — the subscription belongs to the owner's login — and cannot invite, demote or remove another admin.
Buyer	Never this console. A buyer's seat opens only that one buyer's dashboard, with that buyer's calls on it. It is invited from the buyer's Seats tab, not from Team, and it is never counted as one of your plan's seats — see Buyer seats.
Agent	No access to this console. An agent seat is a seat on an agency's call floor, not authority over a tracking workspace.

Authority flows downwards: an owner or admin of a parent account administers the accounts beneath it without needing a seat on each one.

Inviting somebody

On a publisher account, Team invites admins, and only the owner can send the invitation — an admin sees the list but not the form. (An agency account's Team also invites agents to its call floor and partner agencies to run their own team below it.)

1
Send it
Their name and an email address. Send invitation emails them a link, in your brand when you have one. Each invitation is for one address and can be accepted only by somebody signed in as that address.
2
They accept, or say no
The link opens a page that says who invited them to what. Somebody who already has a login signs in and accepts; somebody new sets a name and a password right there — the invitation proves the address, so there is no verification email to wait for — and lands in the console. No thanks declines it, and whoever sent it is told. You are also told when it is accepted.
3
Chase it, or withdraw it
An invitation lasts seven days. Resend issues a fresh link with a fresh week on it — on a pending invitation or an expired one — and the old link stops working. Revoke withdraws it at once. Only the owner can resend or revoke an admin invitation.

The table shows	Meaning
Pending	Sent, and not yet answered. These are the ones to chase.
Accepted	Taken up. The person holds their seat.
Declined	They pressed No thanks. Nothing was set up for them; send a new invitation if they change their mind.
Expired	Seven days passed. Resend re-arms it with a new link and a new week, or revoke it to take it off the list.
Revoked	Withdrawn by you. The link no longer works.
Seats open	What your plan leaves. An admin invitation takes a seat; a buyer's seat never does.

One pending invitation per person per thing: inviting the same address to the same workspace twice answers 409 invite_pending, naming the first — resend that one. The same person may still be invited to one of your buyers, or to a sub-publisher's portal, at the same time.

Changing a role later

Team lists every seat with its role. An admin seat can be locked, suspended or removed by the owner, and removing a seat ends that person's access immediately. Every change is written to the activity log at high severity.
Ownership moves by promotion. The owner seat cannot be demoted directly — promote an admin to owner and the previous owner becomes an admin in the same movement. A workspace can never be left with no owner, and never with two.
Only the sitting owner, or our staff acting on the account, may change who the owner is.
The owner cannot be removed or locked either. Transfer ownership first. It is the same rule from the other side: there is no sequence of steps that leaves a workspace ownerless.
Make somebody an admin rather than sharing the owner's login. They get the same day-to-day access, and only one of them is attributable.

A membership also carries a status. active is the normal one; locked and suspended stop somebody acting without removing the record of what they did, which is the right tool for a colleague who is on leave or under review. Removal destroys the membership; their entries in the activity log stay, because the log is not theirs to take away.

Administering more than one workspace

Owner and admin authority flows down the account tree, so a parent's admin administers every workspace below it without holding a seat on each. That raises a question the platform refuses to guess at: which workspace is this request for?

Hold a seat on exactly one workspace and it is assumed. Nothing to choose, nothing to send.
Hold seats on several and the request must name one — ?agencyId= on the API, and the dashboard switcher in the console. The thing you are about to create is a number or a buyer somebody is billed for, and picking a workspace on your behalf is how it lands on the wrong bill.
Hold none, and the console's API answers 404 "Workspace not found" — call tracking is administered by a workspace owner or admin, and a login without that seat is told nothing more.
An API key never has this problem. A key belongs to exactly one workspace and acts as it, which is another reason not to share one between businesses.

One login can hold many seats: the owner of one publisher account can be an admin of another, a buyer of somebody else's calls and a sub-publisher's portal login, all at once. The switcher shows one tile per seat, and each person lands on the dashboard they used last.

People, buyers, sub-publishers and keys are four different things

	A team member	A buyer's seat	A sub-publisher's login	An API key
Is	A colleague.	Somebody at a company you sell calls to.	Somebody at a company that sends you calls.	A program.
Signs in to	Your console.	That buyer's dashboard: their calls, their destination.	The sub-publisher portal, which shows their side only.	Nothing. It calls the REST API.
Invited from	Team.	The buyer's Seats tab — one seat per buyer.	The sub-publisher's Portal tab.	Created under API keys.
Holds	A role: owner or admin.	Two switches you set: see the caller after a call qualifies, change their own destination.	A seat on that sub-publisher, invited by you or by them.	Scopes.
Can see your prices and margin	Yes.	Never.	Never.	Yes, within its scopes.
Appears in the activity log as	`user`	`user`, on the buyer's record (`via: seat`)	`publisher_member`	`api_key`, named by its label

Our own support staff appear as staff in your log when they act on your account, not only in ours.

Worked example: bringing on a media buyer

You have hired somebody to run campaigns and buy traffic. They need to change routing plans and read every report, and they should not be able to change the plan or move money.

Check Seats open first. If the plan is full, the invitation cannot be sent and you will want to sort that out before promising a start date.
As the owner, invite them as an admin, to their work address — not a shared inbox, for the reason below.
They open the link, set a password and land in the console. Admin covers campaigns, buyers, targets, sub-publishers, numbers, webhooks and keys; the owner keeps the plan, the card and the team.
Do not give them the owner seat. If they leave, you remove an admin seat; an owner seat has to be handed over first.
If they also need programmatic access, issue them their own API key named after what it does, rather than sharing an existing one.
A fortnight later, read the activity log filtered to them. It is the fastest review you will ever do, and it is only possible because they signed in as themselves.

What a team member can reach

An owner or admin can do everything in the publisher console except what the table at the top keeps for the owner. A few things are worth knowing about before somebody discovers them.

They can	Consequence worth knowing
Set a campaign live, or pause it	A live campaign means strangers' calls start reaching somebody's phone. Pausing stops that on the next call.
Change a routing plan	It takes effect on the next call. Calls already in progress keep the plan they were routed on.
Change a buyer's price, caps or destination	Only for calls that arrive afterwards. A call's terms are frozen when it arrives — see Conversions and adjustments.
Let a buyer's seat see callers' numbers	The seat sees a caller's whole number once a call qualifies, and every first sight is recorded in the activity log at high severity.
Correct a call's books	Your reports change, including reports covering past dates. Nothing moves a wallet.
Export the call log	A file of your callers' numbers leaves the platform, and the activity log records it at high severity.
Create and revoke API keys and webhooks	A key is a credential with your workspace's authority. Name it after what uses it.

The same applies to programs. A key shared between two jobs means revoking it breaks both, which is how a leaked key stays live for a fortnight.
Remove people when they leave, the same day. Removal ends access immediately and is itself an entry in the log.
Rotate anything a departing colleague knew: keys they used, and webhook signing secrets they had copied.

Next steps

See who changed whatEvery configuration change, with before and after.Give a buyer their own dashboardOne seat per buyer, and what it never shows.Give a sub-publisher their own viewThe portal, and what it never shows.Credentials for programsScopes, allowlists and rotation.