Skip to content
Skip to main content

Sending messages with Nylas

Last updated:

The Nylas Email API lets you send messages on behalf of authenticated users through their own email provider. You can either send a message immediately or create a draft and send it later. Both approaches use the same REST API, and the provider sees the activity as the user sending the message directly.

Before you start sending messages, you need the following prerequisites:

  • A Nylas application.
  • A working authentication configuration. Either…
    • A Nylas Dashboard Sandbox application which includes a demonstration auth config, OR
    • A provider auth app (Google or Azure), and a connector for that auth app.
  • A Google or Microsoft grant with at least the following scopes:
    • Google: gmail.send
    • Microsoft: Mail.ReadWrite and Mail.Send

If you haven’t set up your Nylas application yet, complete the Getting Started guide first.

Start with who the email is from. This page covers sending from a grant: a connected user’s mailbox or an Agent Account. To send from your own domain without a mailbox, use Transactional Send. To send automatically when an event happens, use a workflow.

Choose who the email comes from

Start with who the email should come from. That decides which kind of send to use. Email from a mailbox (your user's or an Agent Account's) can then go out now, as a draft first, or at a scheduled time.
Diagram as text
  • Your app: You need to send an email: Pick whose address it comes from. Whichever you choose, the API response tells you straight away whether Nylas accepted the message, and Nylas can notify your app later about how the send turned out.
  • Ends in one of:
    • It should come from your user → Your user's own mailbox: For email a real person would send, like a sales rep's follow-up or a recruiter's interview invite. Recipients see your user's address and reply to them.
    • It should come from your AI agent → An Agent Account: For an AI agent that needs its own email address, such as a support or scheduling assistant, so it can send and receive email with anyone.
    • It should come from your product → Your company's domain: For email your product sends itself, like receipts, password resets, and alerts, from an address such as [email protected]. This is transactional send.
    • It should go out automatically → A workflow: For email that goes out whenever something happens, like a booking confirmation, without your app sending each one. It sends from your user's mailbox or your company's domain.

From a grant, you can send a message in three ways:

When a grant's message goes out

A grant is a connected mailbox: a user's account or an Agent Account. These options control when its message goes out, and all three end with the message sent from that mailbox. Send now by default, create a draft when a person reviews the message first, and schedule it with send_at when it must go out later. message.send_success and message.send_failed always fire for scheduled sends, fire for immediate Send Message requests only when you turn on synchronous send webhooks in the Dashboard (Customizations > Notifications), and never fire for Send Draft.
Diagram as text
  • Your app: Your app has a message ready: It goes out from a grant (a connected mailbox). Choose a path by when the message should go out and whether a person reviews it first.
  • One of these paths:
    • Send now (recommended by default)
    • Draft first (recommended when a person reviews)
    • Schedule for later
      • Your app: Schedule the message: Your app sends the message with a future send time (send_at). Nylas returns a schedule_id you can use to cancel it. Request: POST /v3/grants/{grant_id}/messages/send with send_at.
        • Where it waits: Nylas holds it (default). send_at must be 1 minute to 30 days ahead.
        • Where it waits: The user's Drafts folder holds it when you set use_draft: true, with no maximum. Google and Microsoft only. This is what scheduling a draft means: you can't schedule a draft you already created.
      • Nylas: Hold it until the send time: You can still cancel up to 10 seconds before the send time. Request: DELETE /v3/grants/{grant_id}/messages/schedules/{scheduleId}.
  • Provider: The mailbox sends the message: The user's email provider (or Nylas, for an Agent Account) sends the message from the grant's own address, so recipients see that address as the sender.
  • Ends in one of:
    • Accepted → Sent: The message appears in the mailbox's Sent folder. Nylas notifies your app with message.send_success for scheduled sends, and for Send Message when synchronous send webhooks are on.
    • Rejected → Failed: For immediate sends, the API response contains the error. Nylas notifies your app with message.send_failed for scheduled sends, and for Send Message when synchronous send webhooks are on.
  • Send a message directly: compose and send in a single request. Use this when your app writes the message and no one needs to review it.
  • Create and send a draft: prepare a message, save it as a draft synced with the provider, and send it when ready. Use this when a person reviews or edits the message before it goes out.
  • Schedule a message: add send_at to a Send Message request. See the scheduled send lifecycle for how Nylas holds, cancels, and reports on scheduled messages.

Sending a message directly and sending a draft are both synchronous. The request blocks until the provider accepts or rejects the message. If the provider throttles the send, Nylas returns the 429 right away without retrying, for every provider. When the provider says how long to wait, the response includes a Retry-After header with that number of seconds. Your application decides whether and when to retry. Agent Accounts are the exception: a send over the per-second rate limit can be queued and return 202 Accepted instead of 429. See Send queueing.

When you make a Send Message request, Nylas connects to the provider and sends the message as the user. Providers see this as the user sending directly, not as an external platform acting on their behalf. This gives you high deliverability, but messages are subject to the provider’s rate limits and abuse detection. See Improve email deliverability for best practices.

To prepare a message you don’t need to send immediately, create a draft and send it later. Nylas syncs the draft with the provider’s Drafts folder. Metadata you set on the draft carries over to the sent message.

Make a Create Draft request with the message content:

The Create Draft request body accepts the same fields as the Send Message request, with these differences:

  • to is optional for drafts (you can save an incomplete draft).
  • starred (boolean) is supported for drafts but not direct sends.
  • send_at and use_draft are not available on Create Draft. Use Send Message with send_at for scheduled sends.

When you’re ready, send the draft by making a Send Draft request:

To send a message without creating a draft, make a Send Message request:

FieldTypeRequiredDescription
toarray[object]YesRecipients. Each object includes name (string) and email (string, required).
subjectstringNoEmail subject line.
bodystringNoMessage body. HTML is supported unless is_plaintext is true.
is_plaintextbooleanNoWhen true, body is sent as plain text instead of HTML. Default: false.
ccarray[object]NoCC recipients. Same format as to.
bccarray[object]NoBCC recipients. Same format as to.
fromarray[object]NoSender override. See Override sender display name.
reply_toarray[object]NoReply-to addresses. Same format as to.
reply_to_message_idstringNoID of the message being replied to. Nylas adds In-Reply-To and References headers automatically.
attachmentsarray[object]NoFile attachments. Each object includes filename, content (Base64-encoded), and content_type. See Attachments. For files larger than 25MB on Microsoft grants, use the large attachments flow and pass { "id": "<attachment_id>" }.
custom_headersarray[object]NoCustom email headers. Each object includes name and value. See Headers and MIME data.
tracking_optionsobjectNoOpen, link click, and thread reply tracking. See Tracking messages.
send_atintegerNoUnix timestamp for scheduled delivery. Must be at least 1 minute in the future, max 30 days. See Scheduling messages.
use_draftbooleanNoGoogle and Microsoft only. When true with send_at, saves the message in the Drafts folder until send time. Default: false.
templateobjectNoTemplate to merge into the message. Includes id (required), strict, and variables. See Templates and workflows.
metadataobjectNoString key-value pairs. Max 50 pairs, keys max 40 characters, values max 500. See Using metadata.

For the full schema including nested object details, see the Send Message API reference.

You can set the sender’s display name by including the from.name parameter in your request.

curl --request POST \
--url 'https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/messages/send' \
--header 'Authorization: Bearer <NYLAS_API_KEY>' \
--header 'Content-Type: application/json' \
--data '{
"subject": "Reaching out with Nylas",
"to": [{
"name": "Leyah Miller",
"email": "[email protected]"
}],
"from": [{
"name": "Nyla",
"email": "[email protected]"
}]
}'

If you don’t include the from field, Nylas uses the account’s default display name.

You can automatically append an HTML signature to any outgoing message by including the signature_id field in your request body. Nylas appends the signature after the message body at send time, including after quoted text in replies and forwards.

curl --request POST \
--url 'https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/messages/send' \
--header 'Authorization: Bearer <NYLAS_API_KEY>' \
--header 'Content-Type: application/json' \
--data '{
"subject": "Quarterly update",
"to": [{
"name": "Leyah Miller",
"email": "[email protected]"
}],
"body": "<p>Hi Leyah, here is the quarterly update...</p>",
"signature_id": "<SIGNATURE_ID>"
}'

The signature_id field also works on Create Draft and Send Draft requests. See Using email signatures for the full guide on creating, managing, and integrating signatures.

  • Send operations are synchronous. The request blocks until the provider accepts or rejects the message. Nylas returns a throttled send as a 429 without retrying it, so your application owns retries. Wait the number of seconds in Retry-After when the response includes it. On Agent Accounts, a send over the per-second rate limit can be queued and return 202 instead.
  • Use idempotency keys for safe retries. Pass an Idempotency-Key header to retry without sending duplicate emails. See Idempotent send requests.
  • Provider rate limits apply. Each provider limits how many messages you can send per day. See Provider rate limits for details. For high-volume sending, consider a transactional service like SendGrid, Mailgun, or Amazon SES.
  • Microsoft and iCloud don’t support List-Unsubscribe-Post or List-Unsubscribe headers. Nylas can’t add these headers for messages sent from Microsoft Graph or iCloud accounts.
  • Some providers move messages between folders after sending (for example, from Outbox to Sent), which may trigger multiple message.updated notifications for a single send.
  • Nylas de-duplicates some webhook notifications, so you may receive a message.updated notification instead of a message.created notification after sending.
  • Bounced messages are detected automatically. See Bounce detection below.

Subscribe to the message.send_success and message.send_failed notification triggers to track the outcome of a send.

By default, these webhooks fire only for scheduled sends (sends that use send_at). To also receive them for synchronous (immediate) sends, enable Synchronous send webhooks in the Nylas Dashboard: open your application, go to Customizations → Notifications, and turn on the setting.

Nylas monitors for and notifies you when a user gets a message bounce notification. A bounce notification is a message sent by a recipient’s provider when a message can’t be delivered. It usually includes a detailed error message explaining the cause.

When a user receives a bounce notification, Nylas scans it and extracts the reason from the error message.

Messages can bounce for temporary or permanent reasons:

  • Soft bounces have a temporary root cause, like the recipient’s inbox being full.
  • Hard bounces have a permanent root cause, like the recipient’s email address no longer existing.

Currently, Nylas detects hard bounces only and publishes mailbox_unavailable and domain_not_found bounce types.

For more information, see the message.bounce_detected notification schema and Soft vs. Hard Bounce on the Nylas blog.