Sending

Email

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.