Email trigger

You can use an email trigger to start a flow whenever an email is delivered to the flow's unique inbound address. This makes it easy to connect alerting and ticketing tools—most monitoring systems can send email notifications, and pointing them at the flow's address is all the integration you need.

Typical use cases:

• Reacting to alerts from monitoring and observability tools that support email notifications but not webhooks.

• Connecting ticketing systems that send email on ticket creation or updates.

• Processing machine-generated emails with templated bodies: when the plain-text body is valid JSON, the parsed object is available to downstream nodes as jsonBody.

Configuration

• Inbound email address: When you publish the flow, it is assigned a unique address such as [email protected]. Any email delivered to that address starts a run. The address is unguessable and unique to the flow—treat it like a secret. It stays the same when you republish the flow.

• Sender restrictions (optional): Restrict which senders can start the flow. Add full email addresses ([email protected]), whole domains (@example.com), or a mix of both. When the list is empty, any sender can start the flow.

• Require verified sender: When enabled (the default), emails that fail SPF/DKIM authentication for the sender's domain are rejected, so a spoofed sender address cannot start your flow.

Email payload

The email's content is available to downstream nodes as the trigger payload:

Field	Description
from / fromName	Sender address and display name
to / recipientSuffix	The flow address the email was sent to; recipientSuffix carries plus-addressing metadata (an email to wf-abc123+prod@... has suffix prod)
subject	Email subject
textBody / htmlBody	Plain-text and HTML bodies
jsonBody	When the plain-text body is valid JSON, the parsed object—useful for machine-generated emails with templated bodies
headers / messageId / receivedAt	Raw email headers, the Message-ID, and the delivery timestamp
spf / dkim	Authentication verdicts from the mail provider
attachments	Array of attachment objects with metadata and, for supported document types, parsed content (see Attachment content)

Attachment content

For supported document types, the email trigger automatically extracts attachment content and converts it to Markdown, making it available to downstream nodes alongside the attachment metadata.

Each entry in the attachments array contains:

Field	Description
filename	The original file name
size	File size in bytes
contentType	MIME content type
markdown	The extracted document content as Markdown. Empty when the file type is not supported or parsing fails.
parseStatus	Parsing outcome: parsed, truncated, skipped, or error

Supported file types: PDF, Microsoft Word (DOCX), and Microsoft PowerPoint (PPTX).

Parse status values:

• parsed: Content was extracted successfully.

• truncated: Content was extracted but exceeded the maximum length and was cut short.

• skipped: The file type is not supported, the file is empty, or the file exceeds the size limit.

• error: Content extraction failed.

Limits:

• Up to 5 attachments per email are parsed. Additional parsable attachments receive a skipped status.

• Attachments larger than 10 MB are skipped.

• Extracted Markdown is truncated at approximately 256,000 characters.

A flow has at most one run in progress: emails that arrive while the flow is already running are dropped, and re-deliveries of the same email (same Message-ID) are ignored. Like webhook-triggered flows, email-triggered flows cannot be started with the Run button.

Tip

For free-form email text, add an LLM node right after the trigger to extract structured fields (for example, severity, service, or account ID) from textBody before acting on them.

See also

• Trigger node results