Send a message through Mailchimp Transactional
Choose Transactional API or SMTP, inspect per-recipient results, and distinguish queued delivery from final recipient outcomes.
Reviewed
Choose the supported Transactional client for your runtime or the documented SMTP integration. Both use Mailchimp Transactional’s delivery service; neither turns the campaign API into a transactional endpoint.
Submit a controlled one-to-one message
- Load the Transactional credential from a backend secret store.
- Select a sender on the authenticated domain and one approved test recipient.
- Choose plain content or a real stored template and matching merge variables. Confirm the merge language rather than assuming another provider’s template syntax.
- Submit once and inspect the returned per-recipient status, rejection reason where present, and message identifier.
Use Transactional fundamentals and sending links for current SDK calls and SMTP settings. A test key does not prove live mailbox delivery.
Preserve recipient-specific state
Persist your send intent first. An accepted or queued recipient is not proof that every recipient in the request received a message. Store each relevant outcome and correlate later events with provider IDs.
Monitor bounces, rejections, and suppression behavior. Do not repeatedly resend to a rejected address or infer that a timeout means no message was accepted. During a provider cutover, select one transport for a given application operation.
If using MailKite for the replacement path, verify its domain and use its own SDK request model. The main Mandrill sending guide keeps existing application examples and links.