Emails

Transactional email: your app’s password resets, receipts and magic links. They go out from the same verified domain and draw on the same monthly allowance as your campaigns, so there is no second provider and no second reputation to manage.

The request shape is Resend-compatible, so an existing integration usually only needs its base URL, key and from changed.

The Email object

{
  "id": "eml_0dz4k9x2v7q1",
  "object": "email",
  "from": "Acme <noreply@yourdomain.com>",
  "to": ["jane@acme.com"],
  "reply_to": null,
  "list_unsubscribe": null,
  "subject": "Reset your password",
  "status": "delivered",
  "error": null,
  "tags": { "type": "password-reset" },
  "sandbox": false,
  "created_at": "2026-08-21T09:00:00.000Z",
  "sent_at": "2026-08-21T09:00:01.000Z",
  "delivered_at": "2026-08-21T09:00:03.000Z",
  "bounced_at": null,
  "complained_at": null
}

Status

status walks queued then sent then delivered, or ends at one of bounced, complained, failed, suppressed.

Delivery is asynchronous. A transactional send is a top-priority worker job and never waits behind a campaign drain, so it normally completes in seconds.

Send an email

curl -X POST https://go.day3.app/api/v1/emails \
  -H "Authorization: Bearer $DAY3_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: pwreset-user-8412-1755764400" \
  -d '{
        "from": "Acme <noreply@yourdomain.com>",
        "to": ["jane@acme.com"],
        "subject": "Reset your password",
        "html": "<p>Click to reset.</p>",
        "text": "Click to reset.",
        "reply_to": "support@yourdomain.com",
        "headers": { "X-Entity-Ref-ID": "pwreset-8412" },
        "tags": { "type": "password-reset" }
      }'

Body

At least one of html or text is required.

The response is the Email object with status: "queued", returned as 200.

from must be on a verified domain

Verify the domain in the app under Sending. After that, any local part works without pre-creating a sender: noreply@, receipts@, billing@.

An unverified domain is 403 domain_not_verified. Verify it rather than retrying.

The day3 test address

Every new organization is given one pre-verified address on a day3-owned domain, so your first API send needs no DNS at all. It looks like this:

acme@sandbox.day3.app

The local part comes from your organization name. The exact address is shown in the app under Sending, on the card above the domain list.

That rule is the whole basis of the address. It sits on a sending identity shared by every day3 account, so its reputation is not yours alone to spend. Sandbox already restricts recipients to people who asked for the mail and caps the volume, so the address is allowed exactly as far as those limits reach and no further. The check fails closed: anything it cannot prove is a sandbox send is refused.

Two more consequences worth knowing before you build on it:

• The footer carries day3’s postal address, not yours, because the mail leaves our domain.
• It does not count as your verified domain anywhere in the app. Ticking that step would retire the one piece of setup that lets you reach real subscribers.

So use it to get an integration working on day one, and verify your own domain before you upgrade. The only code change is from.

Multiple recipients

to accepts a string or an array of up to 50 addresses. An array is one message whose To header lists them all, not 50 separate emails. Everyone sees everyone.

Addresses are canonicalized, meaning trimmed and lowercased, then de-duplicated. Each surviving address counts against your monthly allowance.

If you need 50 people not to see each other, send 50 requests.

Custom headers

Up to 20. Anything day3 derives from the body or needs for delivery is rejected with 400:

• Body-derived: From, To, Subject, Reply-To and friends.
• MIME plumbing.
• Authentication and trace headers: DKIM-Signature, Authentication-Results, ARC-*, Received, Sender, Resent-*.
• The unsubscribe headers.
• Our own X-Account-ID and X-Transactional-Email-ID.
• Anything starting with X-SES-.

Limits

Control characters are rejected in subject, header values and addresses, and a display name may not contain <, >, " or \. That is header-injection defence, not style preference.

Retrieve an email

Returns the Email object plus events, the delivery timeline fed by the provider:

{
  "id": "eml_0dz4k9x2v7q1",
  "object": "email",
  "status": "delivered",
  "events": [
    { "type": "sent", "created_at": "2026-08-21T09:00:01.000Z" },
    { "type": "delivery", "created_at": "2026-08-21T09:00:03.000Z" }
  ]
}

List emails

Newest first, cursor-paginated. Filter with ?status=queued|sent|delivered|bounced|complained|failed|suppressed.

curl "https://go.day3.app/api/v1/emails?status=bounced&limit=100" \
  -H "Authorization: Bearer $DAY3_API_KEY"

How suppression works here

Transactional mail deliberately follows different rules from campaigns:

• An unsubscribe does not block a transactional send. Opting out of a newsletter must never stop a password reset arriving.
• A hard bounce, a complaint, or a provider suppression does block it, with 400 email_suppressed. Do not retry: the address is unmailable and trying again damages your reputation.

Bounces and complaints on transactional mail feed the suppression list and count towards the account’s reputation auto-pause exactly like campaign sends do. This is not a separate reputation.

Sandbox mode

On a free plan, sends are real but restricted to addresses of members of your own organization, on a small monthly allowance. Responses carry "sandbox": true.

Upgrading lifts both with no code change. See Authentication.

Errors

Knowing what happened, without polling

Polling GET /emails/{id} works, but webhooks are better: day3 POSTs email.delivered, email.bounced, email.complained and suppression.created to your endpoint as they happen. suppression.created is the one that keeps your own database honest about which addresses are dead.