Understanding the Mailhook Trigger Output

A field-by-field reference for the data a Mailhook trigger produces in Spojit, and how to reference each field with handlebars in the nodes that follow.

Overview

A Mailhook trigger starts a workflow whenever an email arrives at the unique address Spojit generates for it (for example mh-1a2b3c4d5e6f7g8h@mailhook.spojit.com). Once the message is received, Spojit parses it into a structured object and makes that object available to every later node as {{ input }}. The setup guides cover how to generate the address and filter incoming mail, but they do not document the shape of the data the trigger hands downstream. This guide fills that gap.

The mental model is simple: the Mailhook trigger is the start node, and its parsed email becomes the root input object for the whole run. Anywhere a field accepts a template, you can reach into that object with handlebars such as {{ input.subject }} or {{ input.from }}. Knowing the exact field names lets you wire a Condition, Transform, Connector, or Send Email node to the email's contents without guessing.

The Output Object

When a Mailhook trigger fires, the parsed email is exposed as {{ input }} with the following top-level fields:

provider - the mail service that delivered the message, for use in routing or logging.
emailId - Spojit's identifier for this received email. Useful for de-duplication checks and traceability in your own records.
messageId - the original Message-ID header from the sending mail system.
from - the sender's address, for example orders@supplier.com.
to - an array of the addresses the message was sent to.
cc - an array of carbon-copied addresses.
replyTo - an array of reply-to addresses. Use this when you want to reply to the sender rather than to the Mailhook address itself.
subject - the email subject line.
text - the plain-text body of the message.
html - the HTML body of the message, when one was sent.
truncated - a boolean flag that is true when the body was longer than the captured limit and had to be shortened.
receivedAt - the timestamp Spojit received the message.
attachments - an array of attachment references (see below).

Referencing Each Field

Every field above is reachable from any later node that accepts templates. A few worked examples:

Subject line into a Send Email subject: {{ input.subject }}
Plain-text body into a Transform or Connector node: {{ input.text }}
Sender address into a Condition node test: check whether {{ input.from }} equals a known vendor address.
Receipt time into a Connector node that formats dates: {{ input.receivedAt }}

Because to, cc, and replyTo are arrays, address the first entry by index when you need a single value, for example {{ input.replyTo.[0] }}. Since a Mailhook trigger is always asynchronous and never replies to the sender on its own, the standard way to respond is a Send Email node addressed to {{ input.replyTo.[0] }} (falling back to {{ input.from }} when no reply-to was supplied).

The Attachments Array

Each entry in attachments is a lightweight reference, not the file itself. A reference contains:

id - the attachment's identifier within this email.
filename - the file name, for example invoice-1042.pdf.
contentType - the media type, for example application/pdf or image/png.

The references let you inspect what arrived (count, names, types) cheaply. To work with the actual file bytes, add an Attachment node, which is available only in Mailhook workflows. It reads the references the trigger produced and returns the decoded content for matching files. You can then feed that content into a Send Email attachment, a Knowledge document input, or any connector that accepts file data. For example, you can branch on whether anything was attached at all by testing {{ input.attachments }} in a Condition node before the Attachment node runs.

Inspecting the Real Output

The fastest way to confirm the exact values your mail produces is to send one test email to your Mailhook address, then open the run in execution history. The trigger step shows the parsed input object exactly as later nodes will see it, so you can copy field paths straight from there. Miraxa, the intelligent layer across your automation, can also explain what a given field holds or build the downstream nodes for you when you describe the email you expect; ask it something like "Add a Condition node that checks if {{ input.subject }} contains the word invoice."

Tips

Prefer {{ input.text }} for AI extraction and pattern matching: the plain-text body is far cleaner to parse than {{ input.html }}.
Check {{ input.truncated }} before relying on the body being complete. When it is true, drive logic from attachments or headers instead of assuming the full message is present.
Use {{ input.replyTo.[0] }} as your reply target and fall back to {{ input.from }}, since forwarded and system mail often set a different reply-to than the visible sender.
Loop over {{ input.attachments }} with a Loop node when you only need filenames or types; reserve the Attachment node for when you actually need the bytes.

Common Pitfalls

Treating to, cc, or replyTo as plain strings. They are arrays, so index into them ({{ input.to.[0] }}) rather than templating the whole array into a single-value field.
Expecting an html body on every message. Plain-text-only senders leave html empty, so guard against it in a Condition node before you depend on it.
Trying to read attachment bytes from the trigger directly. The trigger only exposes references (id, filename, contentType); the bytes come from an Attachment node, which the designer will not save without a Mailhook trigger present.
Replying to the Mailhook address. The Mailhook trigger never answers the sender by itself, so use a Send Email node aimed at the reply-to or sender address to respond.