Questions · Updated 2026-09-28

How do I set reply-to, cc and bcc on an email?

Set reply-to, cc and bcc on an email with the reply_to, cc and bcc fields of POST /emails. Each takes one address or a list, and GET /emails/{id} returns all three as they were sent. Extra headers go in the headers map.

Set reply-to, cc and bcc on an email with the reply_to, cc and bcc fields in the body of POST /emails. Each takes one address as a string or a list of addresses, in either the plain addr@domain form or Name <addr@domain>. replyTo is accepted as the camelCase spelling of reply_to; when both arrive, reply_to wins. GET /emails/{id} returns reply_to, cc and bcc as they were stored, so what was sent is readable afterwards.

Limits and refusals

Each of to, cc, bcc and reply_to holds up to 50 addresses. A longer list is refused with invalid_parameter, and the message names the list, how many addresses it had and the limit. An address that does not parse is refused the same way: "cc contains an unparseable address: …" with the offending entry quoted. A line break or another control character inside an address is refused before anything else is checked, with a sentence such as "Cc contains a line break." Every one of these has retryable false, so fix the field and send again. POST /emails/preflight takes the identical body and returns the same code, message and fix the send would, without sending, which is the way to check a generated recipient list.

curl -sS -X GET https://api.agentisend.com/emails/9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42 \
  -H "Authorization: Bearer $AGENTISEND_API_KEY"
200
{
  "api_key_id": "9c8f8f0e-3d1a-4d3f-9a1e-2b7c1a0f5e42",
  "attachments": [],
  "bcc": [
    "customer@example.com"
  ],
  "cc": [
    "customer@example.com"
  ],
  "created_at": "2026-09-04T09:14:00Z",
  "domain": "string",
  "from": "billing@yourdomain.com",
  "headers": {}
}
Response

Extra headers

headers is a map of header name to string value, for anything the fields above do not cover. A name that is not a valid header name is refused: "Header name "…" is not a valid header name." A few headers the API writes itself are refused too, with the sentence "Header "…" cannot be set — the send path writes it." Among them are List-Unsubscribe, List-Unsubscribe-Post, In-Reply-To and References: the first two are added for a send that names a subscription topic, and the threading pair is written by the API itself, so a caller cannot forge either. GET /emails/{id} returns headers as stored, and GET /emails/{id}/mime shows them on the wire.

Before a domain is verified, the onboarding sender carries none of this. Its refusal is onboarding_shape_refused, whose catalogue message is "The onboarding sender does not accept cc, bcc, attachments, tracking, or extra headers." and whose fix is "Omit those fields, or verify a domain with POST /domains and send from that domain." So a message that needs a cc or a custom header waits for a verified domain, and Domains and DNS is the route to one.

Next