People, roles, and inbox access
Invite people, choose company roles, and control private inbox access from one place.
Add a person
Owners and admins can open the menu under their name, choose Company settings → People & access, and add a person by name and email. The person receives an invitation and creates their own password. Invitations expire, are bound to the invited email address, and can be revoked before acceptance.
The company owner can invite admins or members. Admins can invite members. When sending the invitation, you can optionally grant read-only or read-and-send access to private inboxes you own.
Company roles
| Role | Company settings | Ownership and admins | Shared inboxes |
|---|---|---|---|
| Owner | Full control | Full control | Read and send |
| Admin | Domains, inboxes, and members | No | Read and send |
| Member | Hidden; members use mail only | No | Read and send |
Company role does not by itself grant private inbox content access. Only the owner can promote someone to admin or transfer company ownership.
Manage a person
Select a person in People & access to review their role and inbox access. Owners can change roles, and owners or admins can send members a secure password-reset link or remove them from the company. Startup Mail never shows or lets an administrator set another person’s password.
Removing someone revokes their company and inbox access without deleting their Startup Mail account. A person who owns private inboxes must transfer those inboxes before they can be removed. The company owner can review the affected addresses and explicitly reassign those inboxes from the person panel without opening their mail. The confirmation makes clear that the new owner gains access to existing messages and attachments; every transfer is audited.
Grant private inbox access
The owner of a private inbox can grant read-only or read-and-send access from either the person panel or the inbox member list. Revoking the grant removes access without removing the person from the company.
API keys and agents
Keys are also permissioned identities. Give each integration the smallest scope set it needs, and revoke a key when its workload is retired. Do not share a broad personal key across unrelated services.