Skip to Content

Mail

Mail lets deployed apps send transactional messages and inspect sent or received mail without wiring a separate email provider into every project. Use it for sign-in flows, invites, receipts, notifications, and workflow updates.

Set up an app sender

Enable email in your app’s configuration and redeploy it:

enable_email: true

The platform provisions the app’s sendmail credentials. When the app sends a message through its sendmail endpoint, the platform queues it and handles verification of the owner’s mail domain before delivery. You do not need to verify a sender yourself before submitting that message.

You can also send directly from Emails → Send email in the dashboard. The platform uses the app’s default sender and prepares it automatically on the first send, even if email was not enabled in the app configuration. You can choose another available app sender in the composer. Domain verification happens before delivery, so no verified sender is required to submit the message.

The composer requires at least one To recipient, a nonblank subject, and message content. Cc and Bcc are optional, and the combined recipient count cannot exceed 50. Plan allowances and storage limits still apply; submitting an email queues it rather than confirming delivery.

For API clients, sendAppEmail also accepts an RFC822 rawMessage through a GraphQL multipart upload. Its To and Subject headers can supply those fields, so to and subject are optional in the schema. The resulting message must still contain recipients, a subject, and content. Raw uploads cannot be combined with textBody or htmlBody.

Features

Transactional sends

Send email from an app with recipients, subject, plain text, HTML, cc, bcc, reply-to, and optional sender fields.

Sent and received history

List sent or received messages by app or owner. This gives support and operations tooling a single place to inspect message status.

Delivery status

Email messages include a status such as queued, sent, delivered, failed, or received so product flows can surface what happened.

Common workflow

  1. Send transactional email from the app backend.
  2. List sent messages when confirming a product flow.
  3. List received messages by app or owner for inbound workflows.
  4. Use message status and timestamps during support investigations.

SDK examples

Send and inspect messages

Send a welcome email, list recent sent messages for the app, and read received messages for an owner.

mail.js
1
const message = await client.emails.send({
2
  app: "da_XYZ",
3
  to: ["user@example.com"],
4
  subject: "Welcome to StackMachine",
5
  textBody: "Thanks for signing up.",
6
  htmlBody: "<p>Thanks for signing up.</p>",
7
  replyTo: "support@example.com",
8
});
9
console.log(message.id, message.status);
10
 
11
const sent = await client.emails.sent
12
  .list({ app: "da_XYZ", limit: 10 })
13
  .autoPagingToArray({ limit: 25 });
14
console.log(sent.map((item) => [item.subject, item.status]));
15
 
16
const received = await client.emails.received.list({
17
  owner: "owner_id_example",
18
  limit: 10,
19
});
20
console.log(received.data);

Source: stackmachine/sdks  JavaScript examples.