Send transactional mail with Elastic Email v4
Choose the transactional sending operation, use a matching v4 client, and distinguish accepted submission from delivery evidence.
Reviewed
Elastic Email exposes transactional and bulk operations separately. Select Send Transactional Email in the v4 reference, then use its linked maintained client/library and matching schema.
Connect the transactional operation
- Load a key with the required operation access from your secret store.
- Select the verified sender and a single controlled recipient.
- Build the request’s documented recipient/content fields for v4. Do not reuse a campaign object or an older API’s form parameters.
- Submit once and store the returned transaction/message correlation with an application send intent created beforehand.
Check template requirements and recipient handling if using a stored template. An API key that can view an account resource need not be permitted to send mail.
Verify and reconcile
Inspect the provider’s event/activity resources and the controlled inbox. Acceptance is not final delivery. Monitor permanent failures and suppression behavior before using the integration for critical application messages.
For validation errors, compare the current v4 schema and sender state instead of broadening permissions. For rate/connection errors, use a bounded recovery policy and investigate uncertain acceptance before replaying the send.
During a MailKite migration, map send intent, provider IDs, templates, and feedback explicitly. Do not send the same operation through both providers or assume their inbound event verification is identical.