Email the document to the buyer
POST/api/v1/transactions/:transaction_id/email
Send the transaction's document to up to five addresses from the platform's verified sender,
with the PDF attached the way the email channel hands it out — a PDF/A-3 hybrid carrying
factur-x.xml for an EU seller, the plain PDF otherwise — plus the XML document itself.
sender_name is a display name only; reply_to is where answers go. message (plain text,
up to 2000 characters) is the seller's own note, shown set apart under the document summary.
The body, rendered in lang and sent as both HTML and plain text, carries the seller's name,
one sentence naming the document, a summary block (document number, issue date, buyer, total —
each line present only when this platform holds the value), the note, what the two attachments
are, and the sending attribution. It is transactional: no tracking, no marketing, no
unsubscribe. The subject is Invoice <number> from <sender_name or organisation name>
(Credit note … for a credit note). Each send is recorded on the transaction's metadata
under emails.
Errors: 404 when the transaction is not the caller's; 409 NO_DOCUMENT when the
transaction has no stored document to send (or is an inbound one); 429 after three sends of
the same transaction in 24 hours; 503 when mail is not enabled on this environment.
403 CELL_DOCUMENT_EMAIL_DISABLED on a dedicated cell, whose customers are not mailed from
the platform's sender until the cell's own sending domain is enabled (CELL_DOCUMENT_EMAIL_ENABLED).
422 EMAIL_ADDRESS_UNDELIVERABLE when a recipient is a reserved test address that can never
receive mail — example.com, .test, .invalid, localhost and the other RFC 2606 /
RFC 6761 reservations, the placeholders an app-store reviewer's test order carries: nothing
is sent, the refusal is recorded under emails with sent: false and the reason, and the
document is unchanged. The message says which address and why.
Request
Responses
- 202
- 422
Successful Response
Validation Error