Send transactional email from a domain

Some email doesn’t belong to a user. Password resets, receipts, and system notifications come from your application, not from someone’s connected inbox. Routing those through a user grant is the wrong model, and you don’t want to make every app user authenticate just so you can email them.

Nylas transactional send fixes this with a domain route. You send from a verified domain instead of a user’s account, so there’s no grant and no OAuth, just your API key and a domain you control.

How do I send email without connecting a user account?

Send a POST /v3/domains/{domain_name}/messages/send request. It mirrors the grant send endpoint, but the route is keyed on a verified domain rather than a grant_id, so no user authentication is involved. You reuse the same to, subject, and body fields you’d use for a normal send. Track the outcome through 4 events: message.transactional.bounced, complaint, delivered, and rejected. The feature is currently in beta.

The request below sends a transactional message from a domain.

Request

curl --request POST \
  --url 'https://api.us.nylas.com/v3/domains/<DOMAIN_NAME>/messages/send' \
  --header 'Accept: application/json' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "to": [{
        "name": "Jane Doe",
        "email": "[email protected]"
    }],
    "from": {
        "name": "ACME Support",
        "email": "[email protected]"
    },
    "subject": "Welcome to ACME",
    "body": "Welcome to ACME! We'\''re here to help you."
}'

How do I set up a sending domain?

You need a domain that Nylas has verified before you can send. For testing, use the free nylas.email domain every account can access; for production, verify your own custom domain so mail comes from your brand. Transactional sends follow the same 3 MB JSON and 25 MB multipart attachment limits as a grant send.

See the transactional send quickstart for the domain verification steps.

Things to know about transactional send

Transactional send is for application-generated mail, not bulk marketing campaigns: think one message to one user triggered by an event, like a password reset or an order confirmation. Because the domain route mirrors the grant route, you can share most of your send code between authenticated and transactional paths and switch only the URL.

The feature is in beta, so behavior is stable but the API may change before general availability. Monitor the 4 message.transactional.* events to confirm delivery and catch bounces, the same way you would for grant sends.

What’s next

• Transactional send quickstart for domain setup and your first send
• Send email for the message field reference the domain route reuses
• Detect and handle bounced email for the transactional deliverability webhooks
• Get real-time updates with webhooks to subscribe to delivery events