Seats and Roles

Your Routy account can have more than one user. You add a teammate under Settings > Team by their email address, then tick the permissions they should have: read reports, update accounts, manage traffic sources, connect channels, and so on. They sign in as themselves and see only what you ticked.

The permission list on that screen is the part you're allowed to give, worked out from three things at once. The permission has to be affiliate-scoped rather than staff-only, your plan has to include the feature behind it, and you have to hold it yourself. If something you expected isn't on the screen, it's one of those three.

Admin rights work differently. account.admin isn't a tick box on the team screen, and no publisher or account manager can grant it. The one self-service way to make a teammate an admin is to hand them the account Owner role in account settings, under contacts. That's a transfer, not an addition: there is one Owner at a time.

• Separate logins, one per teammate, each with its own password and its own reset link from the sign-in page.
• Per-teammate permissions over the surfaces worth splitting up: accounts (read, update, delete), catalog, traffic sources, networks, link monitor, channels and their OAuth grants, reports (read, and authoring presets), click and impression events, search, and notifications.
• Stored account credentials behind a permission of their own. A teammate with accounts.read and accounts.update can work on an account all day; viewing or editing the password you keep for it needs accounts.credentials as well.
• A traffic-source restriction, so a teammate only works with the traffic sources you name.
• An Owner and a Billing contact, each picked from the people on your account. The Owner gets account-level notices and can change who the contacts are. The Billing contact receives invoices and payment-failure email, and can open the Billing section.
• Billing closed to everyone else. Other users can't reach the billing endpoints, and billing email goes to the Billing contact, or to the Owner when there's no Billing contact, rather than to the whole account.
• A seat count on your plan, with your direct members counted against it and shown with your other plan usage.
• A record of every change to brand links, outgoing webhook settings, commission plans, users and API tokens: the before and after value of each column, the user who made it, the API token if it arrived over the API, the IP address and the user agent.

That record is kept for every change, but it isn't a screen you can open. Reading it goes through a sys-admin endpoint, so ask support when you need to know who changed what.

Adding and editing a teammate

A teammate you create belongs to your account and is created as a Publisher. Account Manager is a Routy staff role, not something you assign from your own team screen.

Editing is a merge scoped to what you can grant, rather than a replacement of the record. Untick a permission and it's removed, which is how you take access away. Anything you couldn't have granted in the first place survives the save untouched: a teammate's admin rights, their traffic-source restriction if you didn't change it, and the legacy role every publisher carries. To strip a teammate of everything you control, submit an empty permission list.

A save that would add something you can't grant is refused whole, and nothing about the teammate changes. The message is "Cannot assign roles or permissions you are not allowed to grant", and it names each offender so you know which toggle to undo. Re-sending a permission the teammate already holds isn't a grant, so saving an admin teammate works normally.

A traffic-source restriction can be changed by submitting a new value, but not cleared by leaving it out. Leaving it out means don't touch it.

When a change takes effect

Permissions, admin rights and the contact roles are read into the sign-in token when a teammate signs in. Change them while that person is already signed in and they keep what they had until they sign out and back in. Sessions last longer than they used to, so there are fewer sign-in prompts and a longer wait before an edit reaches someone on its own. If the change is urgent, tell them to sign out.

Taking someone off follows the same rule. Clearing their permissions leaves their current session able to do what it could before. Setting their account to Disabled stops them signing in again, and the token they already hold stops working when it expires.

Access from outside your account

A user who belongs somewhere else can be granted access to your account as a collaborator. Routy staff make the grant, and the two sides of it behave differently.

For a publisher, the set of accounts they can reach lives in their sign-in token, so a new grant shows up at their next sign-in and they move between accounts with an account switcher, one at a time. For an account manager the set is resolved per request instead, which takes about a minute to come through and needs no new sign-in.

Either way every request names the account it applies to, and that name is checked against the set the caller can reach. A request pointed at an account outside it is refused rather than widened. If Routy can't establish what you may see, you see nothing.

Seats

Your plan carries a seat number. Routy counts your direct members against it, meaning the Owner plus the team users on your own account, and shows the count with your other plan usage. Collaborators granted in from elsewhere aren't seats. A plan with no seat line is a single-seat plan, never unlimited.

Today the count is a measure rather than a gate, so passing it doesn't stop you adding a teammate. A team beyond the Owner is itself part of what your plan includes.

A shared login has no answer to the two questions that arrive when a team grows. Who changed this, and how do I stop that person getting in. Per-user logins answer both: changes carry the user who made them, and taking one person out leaves everyone else working.

Splitting the permissions is what makes handing work over cheap. A teammate who holds reports.read and nothing else can pull numbers without being able to edit an account, retire a traffic source or open a stored network password. The surfaces they could break aren't reachable, so you don't have to watch them.

The cost is worth being clear about. Permissions are read at sign-in, so a grant or a revocation isn't an instant lever, and the only way to create an admin without talking to support is to give away ownership. If you want a second standing admin alongside yourself, that's a support request rather than a setting.