Create a Triggered Send Definition or Transactional Messaging definition in Marketing Cloud; record its definitionKey.
For the Transactional Messaging (preferred) flow, POST to {rest_instance_url}/messaging/v1/email/messages/ with a body containing 'definitionKey', 'recipients' array (each with 'contactKey', 'to', optional 'attributes'), and optionally 'content' overrides.
Each recipient in the array is sent an independent message; the response contains a 'requestId' and per-recipient 'responses' with 'messageKey' for tracking.
To check delivery status, GET {rest_instance_url}/messaging/v1/email/messages/{messageKey} using the messageKey from the send response.
For high-volume sends (>10k/batch), batch recipients into groups and implement a retry with exponential backoff on 429 rate-limit responses.
Test in a sandbox BU with a test subscriber key before sending to production lists.
Known gotchas
The Transactional Messaging API (/messaging/v1/) and the legacy Triggered Send SOAP API use different definition models — do not mix endpoint paths between the two.
A 202 Accepted response means the message was queued, not delivered — delivery status must be checked separately via the messageKey endpoint or a triggered send log Data Extension.
The 'contactKey' must match a subscriber record in the All Subscribers list; an unknown contactKey results in a queued-but-undeliverable message with no synchronous error.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp