Send an Email Asynchronously
Queues an email message for asynchronous processing and returns immediately with a request ID.
The email will be processed in the background, and you’ll receive webhook events for all delivery status updates (e.g. dropped, processed, delivered, hard-bounced). These webhook events are identical to those sent for the synchronous /send endpoint.
Use this endpoint when you need to send emails without waiting for processing to complete. This can improve your application’s response time, especially when sending to multiple recipients.
Headers
Body
10001000The campaign identifier. If specified, this ID will be included in all relevant webhooks. It can be up to 48 UTF-8 characters long and must not contain spaces.
If set, you must also provide the matching dkim_selector.
Encoded in Base64. If set, you must also provide the matching dkim_domain and dkim_selector.
If set without a matching dkim_domain, the domain will be taken from the from email address.
Optional envelope sender address. If not set, the envelope sender defaults to the from.email field. Can be overridden per-personalization. Only the email portion is used; the name field is ignored.
A JSON object containing key-value pairs, where both keys (header names) and values must be strings. These pairs represent custom headers to be substituted. Please note the following restrictions and behavior:
- Reserved headers: The following headers cannot be modified:
- Authentication-Results
- BCC
- CC
- Content-Transfer-Encoding
- Content-Type
- DKIM-Signature
- From
- Message-ID
- Received
- Reply-To
- Subject
- To
- Header precedence: If a header is defined in both the personalizations object and the root headers, the value from personalizations will be used.
- Case sensitivity: Headers are treated as case-insensitive. If multiple headers differ only by case, only one will be used, with no guarantee of which one.
Settings to adjust open and click tracking for the message. Please note that enabling tracking for your messages requires a subscription that supports open and click tracking.
Mark these messages as transactional or non-transactional. In order for a message to be marked as non-transactional, it must have exactly one recipient per personalization, and it must be DKIM signed. 400 Bad Request will be returned if there are more than one recipient in any personalization for non-transactional messages. If a message is marked as non-transactional, it changes the sending process as follows:
- List-Unsubscribe headers will be added.

