Sending Mail
Outbound needs a verified sending domain, which is how you prove you control it. Once verified, mail is DKIM-signed with that domain's key, so it authenticates as the tenant rather than as your platform.
Verify A Domain First
# 1. Register it
curl -X POST "$API/v1/domains" \
-H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' \
-d '{"domain_name":"example.com","use_for_sending":true}'
# 2. Ask Sentio which DNS records to publish, then publish them
curl -H "Authorization: Bearer $KEY" "$API/v1/domains/$DOMAIN_ID/dns-records"
# 3. Have Sentio check what has propagated
curl -X POST -H "Authorization: Bearer $KEY" "$API/v1/domains/$DOMAIN_ID/verify"Sentio generates the SPF, DKIM and DMARC records for you, and the verify call checks what is actually visible rather than what you meant to publish. Deliverability covers the records it cannot set for you.
Send
curl -X POST "$API/v1/messages/send" \
-H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' \
-d '{
"from": "hello@example.com",
"to": ["someone@elsewhere.com"],
"subject": "Sent with Sentio",
"text": "Plain text body",
"html": "<p>HTML body</p>"
}'| Endpoint | For |
|---|---|
POST /v1/messages/send | One message, composed from fields. |
POST /v1/messages/send-batch | Up to 1000 in one call. Past that the request is rejected as a validation error rather than truncated. |
POST /v1/messages/send-raw | A pre-built EML you have already assembled. |
POST /v1/messages/send-multipart | File upload, for attachments you do not want to base64 into JSON. |
Threading A Reply
Set in_reply_to to the message you are answering and build references from the parent's chain. That is what makes Gmail, Outlook and Apple Mail file the reply into the existing conversation instead of starting a new one.
{
"from": "support-agent@agents.example.com",
"to": ["customer@example.net"],
"subject": "Re: Order #1234",
"text": "...",
"in_reply_to": "<the-inbound-message-id>",
"references": ["<the-inbound-message-id>"]
}What Happened To It
| Endpoint | Returns |
|---|---|
GET /v1/messages/{id} | Current delivery status. |
GET /v1/messages/{id}/events | The per-message event history. |
GET /v1/messages/{id}/raw | The message as it was sent or received. |
GET /v1/messages | A filterable list. |
Polling tells you where one message got to. To learn outcomes as they happen, subscribe to event webhooks instead: an agent should find out that its reply bounced without being asked to check.
Before You Spend A Send
Hard bounces and ISP complaint reports add addresses to the tenant's suppression list automatically, and RFC 8058 one-click unsubscribe is honoured. GET /v1/suppressions lets you check an address first, which is worth doing for anything generated rather than typed by a human.
Sending to a suppressed address wastes the send and spends reputation you will want later. A hard bounce means the address is gone; an agent that keeps composing replies to it is burning tokens on mail nobody will read.