Skip to content

Sending messages with Nylas

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 quickstart first.

Nylas offers two ways to send email:

  • Create and send a draft — prepare a message, save it as a draft synced with the provider, and send it when ready. Best for messages that need review or editing before sending.
  • Send a message directly — compose and send in a single request. Best for automated or transactional messages that don’t need a draft stage.

Both operations are synchronous. The request blocks until the provider accepts or rejects the message. If the submission fails, Nylas does not retry automatically.

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.

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.
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.
metadataobjectNoKey-value pairs for custom metadata. Max 50 pairs, values max 500 characters each.

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.

Some Exchange servers ignore From headers when sending messages and default to the sender’s account display name. When this happens, Nylas can’t override the display name. The user needs to change it in their account settings instead.

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.

Set your HTTP client timeout to at least 150 seconds. Self-hosted Exchange accounts can take up to two minutes to complete a send request, though the average is about two seconds. If your timeout is too low, your application may drop the connection before the provider finishes processing.

Apply a backoff strategy for 503 errors. Your application may need to wait 10-20 minutes before retrying, or the SMTP server may continue refusing connections. See Sending errors for all error codes.

  • Send operations are synchronous. The request blocks until the provider accepts or rejects the message. If it fails, Nylas does not retry automatically.
  • 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.

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.

Bounce notifications are generated only if the bounced messages are sent through Nylas. If a user sends a message directly through their provider (for example, through the Gmail or Outlook UI), Nylas won’t detect the bounce.

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 bounce detection to work, the bounced message must be properly threaded to the original message. If threading is broken, the webhook notification won’t trigger.

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