Why your email API needs roles, not a shared login
A shared login for a transactional email account is a common shortcut on a small team, and a genuinely risky one: whoever has the credentials can create or revoke API keys, remove sending domains, or change account-level settings, with no record of who actually did it if something goes wrong.
The three roles
Envello supports three account roles: admin, developer, and viewer. Admins manage team membership, billing, and account-level settings. Developers can create and manage API keys and domains without touching billing or team membership. Viewers can see logs and account activity without being able to change anything. That's a narrow, specific split, not a sprawling permissions matrix, on purpose: most teams need "can change things" vs. "can only look" more than they need a dozen granular toggles.
Why this matters more for an email API specifically
An API key with send access can be used to send from your verified domains, which means a leaked or over-shared key is a reputation risk for your sending domain, not just a data-access risk. Scoping who can create and revoke keys to specific roles, rather than everyone sharing one login, is a smaller surface area for that kind of mistake.
Inviting a teammate in practice
An admin sends an invite by email from the dashboard's team settings, choosing the role at invite time (changeable later by any admin). The invited person creates their own login tied to their own email address, so their access can be revoked individually the moment they leave the team, rather than requiring a password rotation that locks out everyone still using a shared credential.
What happens when someone leaves
Removing a team member immediately revokes their dashboard access and any API keys created under their identity, without needing to rotate keys other team members depend on. This is the concrete failure mode a shared login creates: with one login, offboarding someone means changing a password everyone else on the team also needs, which either doesn't happen promptly (leaving a former team member's access live) or breaks everyone else's workflow at the same time.
A realistic incident this prevents
A contractor with temporary access to a shared login creates an API key for a side project, forgets to revoke it when the contract ends, and that key keeps working indefinitely since nobody remembers it exists or who created it. With per-person roles, that contractor's account is removed on offboarding, and any keys created under their identity go with it, closing exactly this kind of forgotten-access gap.
What this doesn't replace
Roles control who can do what inside the account. They don't replace the audit log, which records who actually did do what, a separate and complementary piece covered in its own post. Roles are prevention; the audit log is the record after the fact.