POST /send-raw
Recebe o MIME completo já montado pela aplicação, assina e entrega.
A diferença para o `POST /send` é a fidelidade: o /send remonta a mensagem a
partir de campos (subject, html, text), então anexo, Reply-To, List-Unsubscribe
e qualquer header próprio se perdem. O /send-raw entrega o que você montou, byte a byte.
Se a sua aplicação precisa mandar anexo — uma nota fiscal em PDF, por exemplo — é este o endpoint.
Autenticação
Credencial de cliente, via HTTP Basic:
Authorization: Basic base64(cli_<id>:senha)O token de admin não envia — ver Clientes.
Requisição
curl -X POST http://localhost:8080/send-raw \
-u "cli_a3f9c1d2e4b6:{SENHA}" \
-H 'Content-Type: application/json' \
-d '{
"from": "no-reply@minhaempresa.com.br",
"to": ["cliente@exemplo.com"],
"raw": "From: NFS-e <no-reply@minhaempresa.com.br>\r\nTo: cliente@exemplo.com\r\nSubject: Sua nota\r\n\r\nSegue em anexo.\r\n"
}'| Campo | Tipo | Descrição |
|---|---|---|
from |
string | Envelope-from. Define o domínio, e portanto o kit DKIM. |
to |
array | Destinatários do envelope. Um por entrega. |
raw |
string | A mensagem RFC 5322 inteira, headers e corpo. |
Montar o raw em Python:
from email.message import EmailMessage
msg = EmailMessage()
msg["From"] = "NFS-e <no-reply@minhaempresa.com.br>"
msg["To"] = "cliente@exemplo.com"
msg["Subject"] = "Sua nota fiscal"
msg.set_content("Segue em anexo.")
msg.add_attachment(pdf_bytes, maintype="application", subtype="pdf",
filename="nota.pdf")
raw = msg.as_string()O que o mxout completa
DateeMessage-ID, se ausentes. Sem eles o DKIM não os assina e a entregabilidade cai. Se a sua mensagem já traz umMessage-ID, ele é preservado e vira a chave de correlação na resposta e no ledger.- Normalização CRLF, exigida pela canonicalização do DKIM.
Resposta
Depende do modo. Em modo assíncrono (fila), 202 com os destinatários enfileirados:
{
"message_id": "<1785619031.Ta4eiIKR@minhaempresa.com.br>",
"results": [{"to": "cliente@exemplo.com", "ok": true, "detail": "enfileirado"}]
}Em modo síncrono, 200 com o resultado real da entrega. Ver Fila.
Recusas específicas deste endpoint
| Código | Situação |
|---|---|
| 400 | raw vazio |
| 400 | header From com domínio diferente do envelope |
| 400 | header do conjunto assinado repetido (From, To, Subject, Date, Message-ID) |
| 403 | cliente não autorizado para o domínio, ou domínio ainda pending |
| 413 | corpo acima de 8 MiB |
As duas primeiras existem para não entregar mensagem com assinatura que nunca verificaria no destino:
From divergente — o d= da assinatura sai do header From, mas a chave usada é a do
domínio do envelope. Divergindo, a assinatura não fecha; e permitir a divergência seria
permitir personificação de domínio alheio.
Header repetido — assinamos a primeira ocorrência, e o verificador usa a última (RFC 6376 §5.4.2). Melhor recusar na entrada do que emitir assinatura quebrada.