Seats and Roles

Affiliate businesses stop being a one-person operation faster than the tooling assumes. The media buyer needs to see spend and traffic source performance but shouldn't be approving payouts. The accountant needs to see payouts but doesn't need to touch tracking links. The VA needs to upload creatives and update content but absolutely should not see the bank account or have permission to delete things. Shared logins are how this becomes a security incident waiting to happen — and they're how every small affiliate business runs until they get burned and switch to proper multi-user accounts.

Routy supports multi-user accounts with role-based permissions out of the box. Each team member gets their own login. Permissions are scoped to what they actually need — and never broader than the admin who created them, by design.

After adding teammates, the following becomes available:

• Multiple users on one account, each with their own login, their own password reset, their own audit trail. The end of shared credentials and the security risk that comes with them.
• Predefined roles for the common cases. Publisher and Account Manager cover most setups out of the box — assign the role and the permissions are configured automatically. For setups that don't fit the predefined roles, granular custom permissions are available.
• Granular sub-user permissions across the platform's surfaces: accounts, catalog, traffic sources, networks, link monitor, exports, integrations, payouts, and more. Each surface has its own read/update toggle, so you can give a user read access to traffic sources without giving them the ability to change configurations.
• Permissions inherit cleanly — a sub-user can never have more permissions than the admin who created them, by design. This is the safety net that makes delegated administration safe. An admin who grants a user "everything except billing" can be confident that user can't somehow escalate to see billing through some second-order path.
• Audit trail of who did what, scoped per user. Changes to important configurations (link destinations, postback URLs, payout rules) are attributed to the user who made them, with timestamps. Useful for both investigation when something looks off and for the basic responsibility-and-accountability that multi-user setups require.

The role/permission model is built for the reality that affiliate teams are usually small and informal but the data they handle (financial, customer, regulatory) requires care. The defaults err on the side of restrictive — a new user starts with minimum permissions and gets granted what they need rather than starting with everything and having permissions trimmed.

You invite a user from the team section of your Routy dashboard by entering their email address. The user receives an invitation email, sets their password through a standard self-service flow, and the account is active. From your end, you assign them a role (Publisher, Account Manager, or custom) and optionally trim or extend their permissions on specific domains.

A few practical details:

• Password resets are self-service — users can reset their own passwords without admin intervention.
• Permissions can be changed at any time — granting or revoking access on a specific domain takes effect immediately for that user.
• Removing a user revokes their access immediately but preserves the audit trail of changes they made while active. The user's history doesn't disappear from the activity log.
• The number of seats included on your plan determines how many users you can have. Adding more seats is a plan-level change rather than a per-user purchase, which keeps the math predictable.

The case for proper multi-user accounts is mostly about the moment a single-login operation hires its first person. The shared-login workaround that worked for a solo operator becomes a security risk the moment a second person has the credentials. Password rotation, attribution of changes, and the basic ability to revoke access when someone leaves all require per-user logins. Operations that delay setting this up usually regret it the first time someone leaves on bad terms.

The role/permission model also reduces the cognitive load of having multiple people in the same account. When the media buyer can only see and change what they should be changing, you stop having to worry about them accidentally modifying a postback configuration or deleting a link. The permissions are the guardrails that make delegation safe — without them, every team member is a potential point of expensive mistakes.

For larger operations, the audit trail matters too. Knowing which user changed a payout rule three weeks ago, or who modified a tracking-link destination on a campaign that started underperforming, is the kind of information that's invaluable when something needs investigating and impossible to recover after the fact if it wasn't being captured.