Replying to Inbound Mail in a Mailhook Workflow

Because a Mailhook run never replies to the sender on its own, this guide shows how to add a Send Email node that answers the inbound message using the trigger's replyTo value.

Overview

A Mailhook trigger starts a workflow whenever mail arrives at the unique Spojit address it generates, but the run is always asynchronous: Spojit accepts the message and processes it in the background, and nothing is ever returned to the sender's mail client. There is no built-in "reply" channel the way a synchronous webhook returns a body to its caller. If you want the person (or system) that sent the mail to receive an answer, acknowledgement, or error notice, you have to send that reply yourself as an explicit step in the workflow.

The pattern is straightforward once you know it: every Mailhook run exposes the inbound message as {{ input }}, and that object includes a replyTo array holding the address you should answer to. You add a Send Email node downstream of the trigger, set its recipients to that address, and write a subject and body that reference the original message. Spojit's built-in mail service handles delivery, so no extra connection is required. This guide walks through wiring that reply step, threading the original subject, and handling the cases where there is no usable reply address.

Before You Start

A workflow whose trigger is set to Mailhook, with a generated address you have already pointed mail at. If you have not set one up yet, start with the Mailhook trigger guide linked below.
Any external reply recipients must be on your organization's allowlist at Settings → General → Email recipients, or the Send Email step will be blocked.
Outbound mail from the Send Email node counts toward your workspace's monthly email allowance.

Steps

Step 1: Locate the reply address in the trigger output

Open your workflow in the Workflow Designer and click the Mailhook trigger to review its output shape. Every run makes the inbound message available as {{ input }}, which includes from, to[], cc[], replyTo[], subject, text, html, and receivedAt. The field you want for a reply is replyTo, which is an array. In most cases the first entry, {{ input.replyTo[0] }}, is the address you should answer to. Senders that set an explicit Reply-To header (newsletters, ticketing systems, no-reply gateways) will have that value here, which is often different from from.

Step 2: Add a Send Email node after the trigger

Drag a Send Email node onto the canvas and connect the trigger's output to it. Place it at the point in the flow where you actually know what to say back: a simple acknowledgement can sit immediately after the trigger, while a "your order was created" confirmation belongs after the Connector node that did the work. The Send Email node sends from Spojit's built-in mail service, so you do not need to add or pick a connection for it.

Step 3: Set the reply recipient

In the node's properties panel, set Recipients to {{ input.replyTo[0] }}. Recipients is a comma-separated, templated field, so you can add more addresses if you also want to copy a shared inbox, for example {{ input.replyTo[0] }}, ops@yourcompany.com. Leave Reply-To at its default (the workflow owner) unless you want replies to your reply to go somewhere specific, in which case set it to a monitored address.

Step 4: Write a subject and body that reference the original message

Thread the conversation by reusing the original subject. A common convention is to prefix it, for example set Subject to Re: {{ input.subject }}. The Body field is plain text and templated, so you can quote details from the inbound mail or from later steps. For an acknowledgement you might write:

Hi,

Thanks for your email "{{ input.subject }}" received on {{ input.receivedAt }}.
We have logged it and our team will follow up shortly.

This is an automated reply from Spojit.

Only upstream variables resolve inside these fields. You can reference the trigger's {{ input }} fields and the output of any node that ran before this one, but not the workflow's own name or run status.

Step 5: Decide what happens if the reply fails to send

Set If sending fails to match how important the reply is. Choose Fail the workflow when the reply is the whole point of the run (for example a confirmation the sender is waiting on), so a delivery problem surfaces in your execution history. Choose Continue anyway when the reply is a nice-to-have acknowledgement and you would rather the rest of the workflow keep going even if the mail does not land.

Handling a missing or empty reply address

Not every inbound message carries a usable replyTo value. Automated senders sometimes use a no-reply address, and some messages have no Reply-To header at all, which leaves {{ input.replyTo }} empty. Sending to an empty recipient will fail, so guard the reply step with a Condition node that checks whether {{ input.replyTo[0] }} is present before routing to Send Email. If you want a sensible fallback, you can branch to a copy of the Send Email node that uses {{ input.from }} instead, since from is almost always populated even when replyTo is not.

Tips

Mailhook is always asynchronous and deduplicated per message, so a given inbound email triggers exactly one run and one reply. You do not need to add your own replay guard for duplicate sends.
If the inbound mail arrives with the Mailhook address in Bcc, the run still fires and {{ input.replyTo }} is still populated, so your reply logic works the same regardless of whether the address was in To, Cc, or Bcc.
To reply from your own branded domain rather than Spojit's built-in mail service, swap the Send Email node for a Resend or SMTP connector node using its send-email tool, and map {{ input.replyTo[0] }} into the recipient field there.
Ask Miraxa, the intelligent layer across your automation, to scaffold the reply for you with a prompt like "Add a Send Email node after the Mailhook trigger that replies to {{ input.replyTo[0] }} with the subject Re: {{ input.subject }}", then fine-tune the body in the properties panel.

Common Pitfalls

Replying to from instead of replyTo. When a sender sets an explicit Reply-To header, the two differ, and answering from can route your reply to a no-reply mailbox. Prefer {{ input.replyTo[0] }} and fall back to {{ input.from }} only when the reply-to array is empty.
Forgetting the allowlist. External recipients that are not listed under Settings → General → Email recipients will cause the Send Email step to be blocked, which looks like a silent reply failure if you also chose Continue anyway.
Treating replyTo as a single string. It is an array. Reference {{ input.replyTo[0] }} for the first address rather than the bare {{ input.replyTo }}, which would resolve to the whole list.
Expecting the sender to see HTML formatting from the body. The Send Email body is plain text. Keep your reply readable as plain text rather than relying on markup.