How to Auto-Acknowledge Mailhook Support Intake and Open a Front Conversation
Point a support intake address at a Spojit Mailhook, let an Agent-mode node read each inbound email into a clean structured summary, record it as a new Front conversation in the right inbox, and reply to the customer with a branded acknowledgement and reference number through Resend, all seconds after the mail lands.
What This Integration Does
Support requests arrive as free-form email: long, vague subjects, mixed tone, sometimes a whole thread pasted in. This workflow gives every one of those emails a fast, consistent first touch. A Mailhook trigger receives the mail the moment it is sent, an Agent-mode Connector node extracts a tidy subject, a support category, and a short summary, and Spojit records that intake as a new Front conversation so your team picks it up in the correct inbox already tagged and titled. The customer gets an immediate branded acknowledgement from your own domain via Resend, with a reference number they can quote, so no one is left wondering whether their email was received.
The run is push-triggered: any mail to your Mailhook address starts a fresh execution within seconds, with no mailbox or polling involved. The inbound email is exposed as {{ input }}, the Agent-mode node returns a guaranteed JSON shape via a Response Schema, a Transform node mints a reference number and assembles the acknowledgement text, and the two outbound calls (Front send-message and Resend send-email) leave behind a new conversation plus one outbound email per request. Each message is deduplicated, so a resend of the same email will not open a second conversation. Re-running is safe to test because every execution is independent and leaves its own entry in execution history.
Prerequisites
- A Front connection (API token) added under Connections, with permission to list inboxes and send messages.
- The Front channel ID you want intake recorded against (an email channel attached to your support inbox). Run
list-inboxesonce, or read it from Front settings, and keep it handy. - A Resend connection (API key) with a verified sending domain, so acknowledgements come from an address like
support@yourdomain.com. - A support intake email address or forwarding rule you control, so you can point it at the Mailhook address this workflow generates.
- A new workflow created in the Workflow Designer. You can scaffold the node skeleton by asking Miraxa, then fine-tune each node in the properties panel.
Step 1: Receive the email with a Mailhook trigger
Add a Trigger node and set Trigger Type to Mailhook. Optionally set an Address prefix (1 to 24 characters, for example support; the default is mh), then click Generate email address. Spojit creates a unique address of the form support-<random16>@mailhook.spojit.com. Copy it and point your support intake address or forwarding rule at it. Every email sent there starts a run within seconds; there is no mailbox or OAuth to configure.
To keep noise out, add an optional From allowlist or Subject regex filter on the trigger. The inbound mail is available downstream as {{ input }} with fields including {{ input.from }}, {{ input.subject }}, {{ input.text }}, {{ input.replyTo }}, and {{ input.receivedAt }}. Because the Mailhook trigger is always asynchronous, the sender gets no automatic reply: you send the acknowledgement yourself in Step 6.
Step 2: Extract subject, category, and summary in Agent mode
Add a Connector node and switch it to Agent mode. This lets the agent read the raw email and return clean structured fields. In the prompt, pass the inbound content:
From: {{ input.from }}
Subject: {{ input.subject }}
Body:
{{ input.text }}
Read this support email. Produce a concise corrected subject line,
choose one category from the allowed list, and write a 1-2 sentence
plain-language summary of what the customer needs.
Turn on Response Schema so the output is forced into a fixed JSON shape rather than prose. Define it so downstream nodes can rely on the field names:
{
"type": "object",
"properties": {
"subject": { "type": "string" },
"category": { "type": "string", "enum": ["billing", "technical", "account", "general"] },
"summary": { "type": "string" },
"priority": { "type": "string", "enum": ["low", "normal", "high"] }
},
"required": ["subject", "category", "summary", "priority"]
}
Give the node an output variable such as triage. Its fields are then available as {{ triage.subject }}, {{ triage.category }}, {{ triage.summary }}, and {{ triage.priority }}. Agent mode costs AI credits per run; the Response Schema keeps the output reliable for the steps that follow.
Step 3: Build the reference number and intake text with a Transform node
Add a Transform node to assemble the values you will reuse. Mint a short reference number (for example a date stamp plus a slice of the message id) and pre-build the body you will record in Front:
{
"reference": "SUP-{{ input.receivedAt }}-{{ input.messageId }}",
"frontBody": "New support intake.\n\nFrom: {{ input.from }}\nCategory: {{ triage.category }}\nPriority: {{ triage.priority }}\nReference: SUP-...\n\nSummary:\n{{ triage.summary }}\n\n--- Original message ---\n{{ input.text }}"
}
Give the node an output variable such as intake, so you can reference {{ intake.reference }} and {{ intake.frontBody }} later. If you prefer a tidier reference number, you can derive one with the text connector (slugify or truncate) or the uuid connector (nanoid) inside this part of the workflow instead.
Step 4: Record the intake as a Front conversation
Add a Connector node on the Front connector in Direct mode and pick the send-message tool. This opens a new conversation in Front from the channel you support customers through. Map the fields:
channelId: the Front email channel ID from your prerequisites.to: an array with the customer handle, for example["{{ input.from }}"], so the conversation threads to the right person.subject: the cleaned subject, for example[{{ triage.category }}] {{ triage.subject }}.body: the assembled intake text{{ intake.frontBody }}(HTML is supported in this field).
The conversation now lands in the correct inbox with a clean title and a full summary, so a teammate can pick it up without re-reading raw email. Capture the node output in a variable such as frontMessage.
Step 5: Tag the conversation by category (optional)
To make triage searchable in Front, add a second Front Connector node in Direct mode using the add-tag tool, keyed off the category the agent returned. If a single tag per category fits your setup, map the conversation reference from the previous step and the tag that matches {{ triage.category }}. You can also branch first with a Condition node so that only high priority intakes ({{ triage.priority }}) get an escalation tag. Skip this step entirely if your inbox rules already tag on subject prefix.
Step 6: Send a branded acknowledgement with Resend
Add a Connector node on the Resend connector in Direct mode and pick the send-email tool, so the acknowledgement comes from your own verified domain rather than the built-in mail service. Map the fields:
from: your verified sender, for exampleSupport <support@yourdomain.com>.to: the customer,{{ input.replyTo }}(fall back to{{ input.from }}if no reply-to is present).subject: for exampleWe received your request ({{ intake.reference }}).html(ortext): a short branded acknowledgement that quotes the reference and the summary:
Hi,
Thanks for contacting support. We have logged your request and a
teammate will follow up shortly.
Reference: {{ intake.reference }}
Category: {{ triage.category }}
Summary: {{ triage.summary }}
You can reply to this email to add more detail.
If you do not have a verified domain yet, you can use a Send Email node instead, which sends from Spojit's built-in mail service and needs no connection, though it sends from a Spojit address and the recipient must be on your org allowlist. For a customer-facing acknowledgement, Resend from your own domain is the stronger choice.
Tips
- Keep the Agent-mode prompt focused on extraction only. The narrower the task and the tighter the Response Schema
enumlists, the more consistent{{ triage.category }}and{{ triage.priority }}stay across runs. - Make the reference number something the customer can quote and your team can search: include it in the Front subject, the Front body, and the Resend acknowledgement so all three line up.
- Use the From allowlist on the Mailhook trigger to ignore mail that is not real intake (auto-replies, bounce notices), saving an Agent-mode run on each.
- If an email might carry a PDF or screenshot you want to keep, add an Attachment node (Mailhook workflows only) to fetch the bytes and feed them into the Front message or a Knowledge collection. It is off this critical path, so add it only when needed.
Common Pitfalls
- Using the wrong Front identifier:
send-messageneeds the channel ID, not the inbox ID shown in the Front URL. Runlist-inboxesto confirm the channel that backs your support inbox. - Replying to the wrong address: some forwarded mail has an empty or system
replyTo. Always fall back to{{ input.from }}so the acknowledgement reaches a human. - Expecting the Mailhook trigger to reply on its own. It is always asynchronous and sends nothing back to the sender; the acknowledgement only happens because of the Resend step.
- Resend rejecting the send because the
fromdomain is not verified. Verify your domain in Resend first, or thesend-emailcall will fail. - Treating a resend of the same email as a new ticket. Mailhook deduplicates per message, so the same email will not open a second conversation, but a customer forwarding a fresh copy is a new message and a new run.
Testing
Before pointing real intake at it, generate the Mailhook address and send yourself a couple of realistic test emails (one billing-flavoured, one technical) directly to that address. Open the run in execution history and confirm the Agent-mode node produced a valid triage object matching your Response Schema, that the Front conversation appears in the expected inbox with the cleaned subject, and that the Resend acknowledgement arrived at your reply-to address with the reference number. Once a handful of test emails flow end to end, switch your live support forwarding rule to the Mailhook address and watch the first few real runs.