Skip to main content

Incoming Email

The Incoming Email trigger starts a workflow when a message is delivered to a dedicated Splice email address. Each workflow gets its own inbound address; anything sent to it is parsed and handed to the workflow as structured data — sender, recipients, subject, body, and attachments. It is the right trigger for partners and systems that deliver documents by email rather than by API: BOLs, rate confirmations, invoices, and other attachments that arrive in an inbox today.

Overview​

Use the Incoming Email trigger when you need to:

  • Process emailed documents - Pull BOLs, invoices, PODs, and rate confirmations out of attachments
  • Onboard partners with no API - Give a partner an address to forward to instead of building an integration
  • Capture inbound requests - Turn emailed requests into structured workflow runs
  • Forward existing mail flows into automation - Set up a mailbox rule to forward matching mail to the Splice address

The Inbound Address​

When you configure the trigger you choose an Email Prefix. Splice combines that prefix with a unique suffix and its inbound mail domain to produce the address senders should use:

<prefix>-<unique-id>@email.splice-it.com

For example, a prefix of exportbooking produces an address like:

exportbooking-9y9xtpeg@email.splice-it.com

The generated address is shown on the node after you save. Give this exact address to whoever (or whatever) will send mail — or set up a forwarding rule on an existing mailbox to relay matching messages to it. The unique suffix keeps each workflow's address distinct even when two workflows use the same prefix.

Inbound mail is received through Amazon SES on the email.splice-it.com domain, matched to the workflow by its configured address, parsed, and used to start an execution.

Configuration​

Email Prefix (required)​

A human-readable label for the address (for example, invoices, bookings, pod). It becomes the leading part of the generated inbound address. Choose something that identifies the workflow's purpose — it makes the address easier to recognize in forwarding rules and partner setups.

Email Address​

The full, generated inbound address (read-only). This is the value to hand to senders. It is derived from the prefix and cannot be edited directly — change the prefix to change the address.

Text Email​

When enabled, the plain-text body of the message is included on the trigger output as text. Defaults to off — enable it only if the workflow actually reads the body, since many document-by-email flows care only about attachments.

HTML Email​

When enabled, the HTML body of the message is included on the trigger output as html. Defaults to off.

No sender or subject filtering at the node

The Incoming Email trigger does not filter by sender, subject, or any other header — every message delivered to the address starts the workflow. If you need to accept mail only from certain senders or route by subject, do that in a downstream node (for example, an If or Switch node that inspects from or subject).

Output​

The trigger emits a single output keyed by the node's name. With a node named Incoming Email, a received message produces:

{
  "Incoming Email": {
    "from": [{ "address": "admin@example.com", "name": "Admin McExampleson" }],
    "to": [{ "address": "info@example.com", "name": "Info McExampleson" }],
    "cc": [{ "address": "cc@example.com", "name": "C. C. McExampleson" }],
    "subject": "My subject line",
    "date": "2026-05-30T12:00:00.000Z",
    "text": "Plain text message of email.",
    "html": "HTML text message of email.",
    "attachments": ["trigger-invoices-9y9xtpeg@email.splice-it.com/2026-05-30T12:00:00.000Z/invoice.pdf"]
  }
}
  • from, to, cc - Arrays of { address, name } objects parsed from the message headers.
  • subject - The subject line.
  • date - The message date.
  • text - Plain-text body. Present only when Text Email is enabled.
  • html - HTML body. Present only when HTML Email is enabled (falls back to the plain-text body if the message has no HTML part).
  • attachments - An array of storage paths to the message's attachments. Each attachment is saved to workflow storage on receipt, and the path is what downstream nodes use to read the file. The array is empty when the message has no attachments.

Example Usage & Common Use Cases​

Invoice Intake from a Partner​

A partner emails PDF invoices to a Splice address; the workflow extracts and books them:

Email Prefix: invoices
(address: invoices-xxxx@email.splice-it.com)

[Incoming Email] → [PDF Converter: read invoice] → [Set: map fields] → [HTTP Request: post to ERP]

Restrict to Known Senders​

Accept mail only from an approved address, ignore the rest:

[Incoming Email] → [If: from[0].address == "ap@bigcustomer.com"]
                       ↓ true                    ↓ false
                  [Process invoice]         [Stop / log + ignore]

Route by Subject​

Send different document types down different branches based on the subject line:

[Incoming Email] → [Switch: on subject]
                      ├─ contains "BOL"   → [Process BOL]
                      ├─ contains "RATE"  → [Process rate con]
                      └─ default          → [Send Email: unrecognized]

Forward an Existing Mailbox​

Point a rule on an existing shared mailbox (e.g. documents@yourcompany.com) at the generated Splice address so today's mail flow starts feeding automation without changing what partners send.

How It Works​

  1. Provision the address - Saving the trigger registers a unique <prefix>-<id>@email.splice-it.com address for the workflow.
  2. Receive - A partner (or a forwarding rule) sends mail to that address; Amazon SES accepts it for the email.splice-it.com domain.
  3. Screen - Messages that fail SPF, DKIM, spam, or virus checks are dropped and never reach a workflow.
  4. Match - The recipient address is resolved to the owning workflow. Mail to an unknown or inactive address is ignored.
  5. Parse - The raw message is parsed into structured fields (from, to, cc, subject, date) and each attachment is saved to workflow storage. Body text/HTML is included according to the Text Email / HTML Email toggles.
  6. Enqueue - A workflow execution is started with the parsed message as the trigger output.

Best Practices​

  • Use a descriptive prefix - It makes the generated address self-documenting in partner setups and forwarding rules.
  • Only include the body you use - Leave Text Email / HTML Email off unless the workflow reads the body; it keeps payloads lean.
  • Filter downstream - Because the node accepts all mail to the address, validate the sender or subject early in the workflow and stop on anything unexpected.
  • Keep the address private - The address is effectively a public ingress; anyone who learns it can start the workflow. Treat it like a webhook URL and validate inside the workflow.
  • Plan for malformed mail - Senders vary. Guard against missing attachments or unexpected formats rather than assuming a fixed shape.

Troubleshooting​

Common Issues​

  • Workflow didn't run on a sent email - Confirm the message went to the exact generated address (including the unique suffix), and that the workflow is active.
  • Body is empty - Text Email / HTML Email default to off. Enable the one you need to see text / html on the output.
  • Attachment not found downstream - Check the attachments list on the trigger output for the exact filename, and make sure the downstream node references it correctly.
  • Unwanted senders triggering the workflow - The node has no built-in sender filter; add an If/Switch check on from early in the workflow.

Debugging Tips​

  • Send yourself a test message - Mail the generated address directly and inspect the captured trigger output in the workflow editor before connecting a partner.
  • Check the parsed sample - The trigger output is captured as node sample data on each run, which you can use to design downstream nodes.
  • Webhook - HTTP-based ingress for partners that can push data over an API
  • Trigger Nodes - Overview of all available workflow trigger types