Choose your setup

Mailmus products work on their own. You turn on what your application needs, per project, and add the rest later without rebuilding anything.

This page covers the four setups for signing people in and organizing them into companies. Sending email (Mail) combines with any of them.

1. Authentication only

Your Customers sign up and sign in to your application through Mailmus Auth. There are no organizations to set up.

What you get:

• Sign-in methods: email and password, magic link or email code, SMS code, Google, GitHub and Apple.
• Account security: two-factor authentication with an authenticator app and backup codes, password reset, email verification, lockout after repeated failed attempts.
• Sessions: your Customers see and sign out their devices; you can do it for them.
• Ready-made sign-in pages, with your logo, your colour and your own domain, or React components if you prefer to host them.
• Your server stays in control: it verifies each session locally, without calling Mailmus on every request.
• Customer management: search, ban, reset two-factor authentication, attach your own data to a Customer.
• Roles and permissions: create roles such as moderator with the permissions they grant, give them to your Customers, and ask Mailmus whether someone can do something, with the reason.

Start with Add authentication in 5 minutes.

2. Organizations with your own sign-in

You keep signing people in the way you do today. Mailmus manages the companies that use your product: who belongs to which organization, with which role, and what happened to it.

What you get:

• Organizations for each company, created from your server and identified by your own customer IDs.
• Members identified by your own user IDs. You add a member with the ID your system already uses; Mailmus never asks that person for a password or a Mailmus account.
• Roles inside each organization: three built-in roles (org:owner, org:admin, org:member) and your own, with the permissions they grant. Your server checks access by your own user ID.
• Invitations by email, with their fate on the organization's history: delivered, not delivered, or marked as spam.
• Verified domains: a company proves it owns acme.com by publishing a DNS record. You can then let anyone with an address at that domain into the organization with one call, right after you sign them in, instead of inviting them one by one. Off until you turn it on, and set per domain. See Verified domains.
• A history per organization: who was added or removed, whose role changed, which invitations were sent. It answers the call you get when a customer asks why someone lost access.

Turn it on from Project → Organizations, then see Organizations.

3. Mailmus Auth and Organizations

You already use Mailmus Auth, and your product now serves companies. Everything from the two setups above works together, on the same Customers: nobody signs up again.

What you get on top:

• Invitations accepted in one click: the invited person signs in or creates an account, and joins the organization.
• An active organization per session: a Customer who belongs to several companies switches between them, and the session token tells your server which organization and which role apply.
• Single sign-on for companies: an organization signs its people in through its own identity provider (SAML), on a domain it has proved it owns. A company's identity provider can only sign in people whose email belongs to that company's domain.
• Joining by verified domain: once a company has proved it owns its email domain, anyone signing in with an address there becomes a member, with no invitation to send. Off by default, and decided per domain. See Verified domains.
• Roles on two levels: roles on the Customer for your whole application, and roles in each organization they belong to, checked the same way. See Roles and permissions.

Turn on Organizations from Project → Organizations; your Customers and their sessions are unchanged.

4. Another provider, then Mailmus Auth

You sign people in with another authentication provider today, and you want Mailmus to manage organizations, or to move everything to Mailmus later.

• Now: follow setup 2. Add members with the user IDs your provider gives you.
• Choose one place for organizations. If your current provider also manages organizations or single sign-on, use only one of the two for a given company, so that membership and roles never disagree.
• When you move to Mailmus Auth, members keep their organizations and roles. Include each member's email when you add them: that is what lets them find their memberships again once they sign in with Mailmus.

Next

• Getting Started: create a project and get your keys.
• Add authentication and Organizations.
• API Reference: every endpoint, grouped by product.