Email-code sign-in and Brevo

Deployed backend checked on 26 October 2026. Its configured transport is MAIL_TRANSPORT=brevo. This is a configuration observation, not a deliverability test: no email was sent while writing this page.

Responsibilities

Android / iOS app
  -> POST /auth/email/request: email address
  -> Backend: generates the code and stores its hash
  -> Brevo: sends the email containing the code
  -> User: enters the code in the app
  -> POST /auth/email/verify: backend verification
  -> Backend: issues the user credential after successful verification

These paths are internal API routes; the public entry point may prepend /api.

Brevo delivers the message. The Snag backend generates and verifies the code, authorizes account access and issues credentials. The frontend does not call Brevo directly and must not contain its API key or server secrets.

The code is temporary proof of mailbox access, not the token subsequently used to access account data. The flow can link an email to an existing anonymous account or sign the user into the corresponding account.

Server configuration

Variable	Purpose
MAIL_TRANSPORT	brevo was configured on the VPS when checked
MAIL_API_KEY	Provider secret, backend only
MAIL_FROM	Configured sender accepted by the provider
MAIL_REPLY_TO	Optional reply address

The implementation also supports resend and console. The default console transport writes the code to logs and sends no email. It is inappropriate for public production sign-in. A real transport with a missing key or an absent or invalid sender produces a startup configuration error.

Never put actual values in Git, screenshots, tickets or documentation. Rotating MAIL_API_KEY requires updating the backend configuration and having the service load it; rotating this key alone does not require a new mobile build.

Observed backend protections

• Cryptographically generated six-digit code.
• Ten-minute validity and single use.
• Five attempts per code.
• At least sixty seconds between issues for the same address.
• Request and verification route rate limits.
• Salted scrypt hash in the database, not a plaintext code in that table.

These controls do not attest application authenticity. Email sign-in proves access to a mailbox, not use of an official build or admission to a private beta.

Data and troubleshooting

Brevo receives the recipient address and message content, including the code, to deliver the email. Include this disclosure in the provider and data-processing inventory. It does not give Brevo access to user collections or Snag database credentials.

For delivery issues, check the selected transport, sender, key status and provider delivery events, then spam folders. Do not expose codes, keys or complete messages in shared diagnostic logs. API acceptance does not establish email delivery.

Code references

In tcg-collector-backend:

• src/api/src/routes/authEmail.ts: request and verification.
• src/api/src/auth/loginCode.ts: code generation, hashing and policy.
• src/api/src/mail/mailer.ts: configuration and delivery transports.

See also Backend, API, images and access control.