One message per request. Give it a body, or give it a template and the values to fill it with.
Who it is from
from takes a bare address or a display name: Acme <hello@yourdomain.com>. The domain must be one you have verified. Pass from_name instead if you would rather keep the two apart.
Who it goes to
to, cc and bcc each take one address or a list. Addresses are lowercased before anything else happens. A recipient on your suppression list is dropped rather than sent to, and comes back in suppressed_recipients on the receipt — the send is not an error, it just did not go to that person.
Body or template
Send subject with html, text, or both. Or name a template — by template_id or template_friendly_name, not both — and pass variables. A template brings its own subject.
Send a templatecurl -X POST https://api.transmit.dev/v1/emails \
-H "Authorization: Bearer $TRANSMIT_API_KEY" \
-H "Idempotency-Key: order-1042" \
-H "Content-Type: application/json" \
-d '{
"from": "Acme <hello@yourdomain.com>",
"to": ["you@example.com"],
"template_friendly_name": "order-shipped",
"variables": { "name": "Dana", "tracking": "1Z999AA10123456784" }
}'Attachments
Up to twenty per message, each with a filename, base64 content and a MIME type. Set disposition: "inline" and a contentId to reference one from your HTML. We do not fetch attachments from a URL: what you send is what goes.
Scheduling
scheduled_for takes an ISO 8601 instant with an offset. Credits are charged when we accept the message, not when it leaves, so a scheduled send is already paid for and the receipt says "status": "scheduled".
Tracking
track_opens and track_clicks default to on, and can be turned off per message. Opens and clicks arrive as webhook events and feed the analytics endpoint.
message_stream defaults to transactional. Use broadcast for bulk mail, which is rate-shaped separately so a campaign cannot delay a password reset.