Auth — email one-time codes as a second factor
MFA factors are no longer TOTP-only: enroll an email factor and your end-users receive a single-use 6-digit sign-in code at their verified address — with delivery through your own Mail sender domain.
Every MFA surface now accepts type: "email" alongside totp. Self-service enrollment (POST /:app/v1/me/mfa/factors) sends a confirmation code to the user's verified email and enables the factor when it is submitted; admin provisioning (POST /:app/v1/users/:id/factors) creates the factor already enabled against the user's verified address — handy for bot and service accounts that have a mailbox but no authenticator app. Recovery codes work the same for both factor types.
At sign-in, the mfa_required challenge lists each factor's type and (for email factors) a masked destination. Request delivery with the new POST /:app/v1/auth/mfa/send-code, then complete the challenge through the existing /auth/mfa/verify. Codes are single-use, expire after 5 minutes, and sends are throttled per challenge and per address. Step-up flows get the same treatment via POST /:app/v1/me/mfa/step-up/send-code.
Delivery routes through your workspace's verified Mail domain: a new Sign-in code (email MFA) template slot joins verification, welcome, and password reset in the console under Auth → App → Integration → Notifications (a sensible default template is seeded for you). Email factors always bind to a verified contact — unverified addresses are rejected at enrollment.