Emails

This page explains which emails Bastide sends for your project today, how those sends are handled (retries, caps, bounces), and what does not exist yet: sending your own transactional emails, a sending domain of your own, and monthly quotas per tier.

What exists today

For your project, the platform sends your users' authentication emails:

The flow and the links are described in Authentication. Templates are the platform's, in French, with your project's name.

What does not exist yet

• Sending your own emails (invoice, notification, newsletter) through Bastide: no API, no tool and no SMTP relay is open to your application. Use your own provider from your code; your project's outbound network must then allow it (see Firewall).
• A sending domain of your own. Emails leave from the platform's relay and sending address; you set neither the sender, nor the domain, nor its SPF or DKIM records.
• Custom templates per project.
• Monthly quotas per tier. The price grid states 1,000, 10,000, 50,000 and 200,000 transactional emails a month from Discovery to Sovereign; these quotas are not enforced yet, and nothing is billed beyond them. Only the hourly cap below applies.

How sends are handled

Retries

An email is placed in a queue, then handed to the relay. A temporary failure is retried on a fixed schedule: eight attempts, the last one 24 hours after the first.

After the eighth, the email is given up. An email still waiting after 48 hours is given up without being sent: an authentication link that old would open nothing. A send can, rarely, arrive twice; the link works only once.

Caps

• Per project: at most 100 emails an hour, through the shared relay. Beyond that, the email is logged and not sent; your application is not told, because an authentication flow never reveals whether a message went out.
• Per address: 4 emails an hour by default, adjustable from 1 to 40 (see Authentication). Beyond that, the call gets 429, debit_depasse.

Bounces and complaints

A hard bounce or a complaint suspends the address for your project: any later send to that address is closed without going out, reason adresse_suspendue. The suspension lifts by itself 90 days after the last bounce. A relay outage is never counted as a bounce.

What the platform keeps

The sending log is kept 30 days: kind, state, attempts, the relay's answer (truncated to 512 bytes, address removed), and bounces and complaints that came back after delivery. What an email carries (the address, the token, the code) is sealed when queued and erased as soon as the send is closed, delivered or not. The suppression list keeps only a fingerprint of the address.

Reading the sending log

• Console: the Authentification (Authentication) screen, « Courriels d'authentification » (authentication emails) card.
• Agent: auth_email_list (rank developer, scope db:read), with the state filter (pending, delivered, rejected, dead) and withReturns (only emails that came back after delivery).
• Command line: bastide auth_email list --project-id <project> --state dead.
• API: GET /v1/projects/{projectId}/auth-emails.

{
  "projectId": "prj_01JQ8ZK4M7NP2RSTVWXYZ34567",
  "state": "rejected",
  "limit": 25
}

Common errors

• A user receives nothing: find their email in the log and read its reason. adresse_suspendue: the address bounced; it is released 90 days after the last bounce. sans_adresse_de_site: set the project's site address.
• Many sign-ups without an email: the project's cap of 100 emails an hour may have been reached, for instance by automated sign-ups; lower the sign-ups per hour per IP address.
• **429 debit_depasse** on a link request: the per-address limit was reached.

See also

• Authentication, Firewall, Notifications, Limits by tier
• Reference: auth_email.list

Report a mistake on this page