Interface: SendEmailOptions
Delivery-time options that are NOT part of the message a model composes.
Deliberately separate from EmailMessage: that schema is the agent tool’s input, so anything added to it becomes a field a model can set. These describe how a message is DELIVERED, so they are the caller’s to supply.
Properties
Section titled “Properties”heading?
Section titled “heading?”
optionalheading?:string
Visible heading inside the branded HTML card. Defaults to the message subject. Use this when the transport subject carries notification-specific details that would be noisy if repeated inside the opened email.
preview?
Section titled “preview?”
optionalpreview?:string
Preheader text for the HTML part - the snippet shown beside the subject in an inbox list, and the body of the PUSH NOTIFICATION a mobile mail app posts. Defaults to the subject.
Delivery-time rather than part of EmailMessage for the same reason as
text: it is presentation the sending CODE chooses, not content a model
composes. The one-time-code path sets it so the code itself rides in the
notification, which is the only text iOS autofill gets to read.
optionaltext?:string
An explicit text/plain alternative, replacing the one generated from the
React Email tree. The HTML part is untouched, so the recipient still gets the
full branded template.
This exists because the generated text part is a RENDERING of the HTML: it
carries the brand header and footer, and it turns CSS margin into blank
lines. That is fine for prose and wrong for content a machine parses. A
one-time-code email is the case in point - clients look for the code on the
line immediately after the prompt, and a styled <h2> code lands two blank
lines below it, so autofill stops being offered even though the HTML looks
perfect. Supplying the text part directly keeps the nice template AND the
layout those clients expect.
Keep the same information in both parts; a text alternative that disagrees with the HTML reads as phishing to spam filters.