Connecting Front to n8n: automatically sort and route shared-inbox conversations
Published 31 August 2026 · 6 min read
A Front inbox shared across several teams — support, sales, operations — quickly piles up dozens of conversations a day, arriving by email, chat, or social media, all sitting in a single queue with no automatic distinction between a basic question and an urgent request from a strategic client. Front's own Rules cover simple keyword-based tagging and assignment scenarios, but stop short of actually understanding the content. This guide shows how to wire n8n into Front through its Rule Webhooks and REST API, to classify each incoming conversation with an LLM, route it to the right team, and alert Slack on urgent ones.
No Front node, native or community
n8n has no native Front node (n8n-nodes-base). Unlike Crisp or Gorgias, there is no maintained community node for this service on npm either — searches only turn up unrelated packages (Frontify, FrontMatter). The HTTP Request node, combined with n8n's Webhook Trigger, is therefore the only reliable path, and it works identically self-hosted and on n8n Cloud; our guide to community nodes covers the precautions worth taking when such a node does exist but isn't verified. If you haven't settled on a hosting choice yet, our self-hosted vs. Cloud comparison helps weigh that criterion.
Rule webhook or application webhook: two distinct mechanisms
Front offers two ways to push events to an external URL, with different security logic:
- Rule webhook: an action added to a standard Front rule (Rules menu, WHEN > IF > THEN structure). It's configured in a few clicks with nothing else to build on the Front side beyond the rule itself — the fastest option for internal use.
- Application webhook: tied to a full Front app, activated through an
X-Front-Challengehandshake and auto-disabled after three consecutive failures. This mechanism targets published integrations meant for multiple Front accounts, not internal use — unnecessarily heavy for this guide.
This guide therefore sticks to the rule webhook, which is more than enough to sort and route conversations for a single organization.
Generating and securing the API credentials
From Settings > Developers > API tokens, generate a token for use within a single organization; Front also supports OAuth2, relevant for an agency running several client accounts from the same n8n instance, on the same principle already covered in our guide to hosting n8n for a multi-client agency. Every call authenticates with an Authorization: Bearer <token> header against the base URL https://api2.frontapp.com. Create an n8n credential of type "Header Auth" rather than pasting the token in plain text into every HTTP Request node: our guide to securing API credentials covers this practice.
Configuring the rule webhook on the Front side
In Rules, create a rule triggered on "Message received," with no restrictive condition if you want to classify the entire incoming flow, then add the Webhook action pointing to your n8n Webhook Trigger's test URL. Switch to the production URL once the workflow is active.
Every call is signed with an X-Front-Signature header, computed as HMAC-SHA1 over the raw request body using your API Secret (visible in your organization's settings) — a different scheme from the HMAC-SHA256 over timestamp:body used by Front's application webhooks, worth not confusing if you later migrate to that second mechanism. Recompute that signature in a Code node before processing anything: the general principle is the same as the one covered in our guide to securing n8n webhooks, only the computation mechanics differ.
Building the sorting workflow
The pipeline reuses a structure already proven on this blog for support ticket scoring, applied here to Front's stream:
- Webhook Trigger — receives every event from the rule; a Code node verifies
X-Front-Signature, then an IF node filters incoming visitor messages, excluding internal notes or messages already sent by an agent. - AI node — sends the message content, the conversation subject, and the originating channel (email, chat, SMS, social — Front unifies all of them into a single conversation structure) to an LLM with a structured output (urgency, category, target team), on the model described in our guide to the Structured Output Parser.
- Switch — routes by category: a sales inquiry moves to the sales team via the
inbox_idfield, a critical support issue triggers a Slack alert on the pattern already documented for human approval via Slack, and everything else is simply tagged and assigned to stay traceable inside Front.
Tagging, assigning, and moving through the REST API
A single call covers most of the sorting logic: PATCH /conversations/{conversation_id} accepts tag_ids (replaces the conversation's tags), assignee_id (assigns it to a specific teammate), and inbox_id (moves the conversation to another inbox), returning a 204 with no body. That same endpoint therefore handles both silent sorting (tag only) and full routing (tag + assignment + move) in a single call instead of three.
Front enforces its quota per organization, not per token: 50 requests per minute on the Starter plan, 100 on Professional, 200 on Enterprise, with a separate cap of 120 requests per minute for OAuth partner integrations. On top of that come per-resource, per-second caps — 5 requests/second for conversations, messages, and channels, 1 request/second for exports — a budget worth watching like any API quota described in our guide to rate-limiting AI APIs, especially if other tools (a CRM, reporting) share the same Front organization.
Concrete use cases
- Agency managing several brands: a single Front rule, one n8n workflow parameterized by
inbox_id, sorting conversations across several clients' channels at once — the same mutualization logic described in our guide to hosting n8n for a multi-client agency. - Shared sales inbox: an incoming message containing a buying-intent signal gets tagged and assigned directly to the rep covering that territory, on the same principle detailed in our guide to AI-based inbound lead qualification.
- Multichannel support: a conversation arriving by SMS or social media follows the same classification pipeline as an email, since Front unifies them into a single conversation structure — the main benefit of routing from Front rather than from each channel separately.
Pitfalls to avoid
- Mixing up the two signature schemes: verification code written for an application webhook (HMAC-SHA256 over timestamp+body) fails silently on a rule webhook (HMAC-SHA1 over the body alone), and vice versa.
- Forgetting the quota is shared per organization: a burst of bulk tagging triggered by n8n can eat into the call budget of other tools connected to the same Front account; spreading bulk operations over time avoids this conflict.
- Treating outgoing messages as incoming ones: without a sender filter, an agent's reply needlessly re-triggers the workflow — always check the sender's role before classifying anything.
- Not handling retries: like any webhook, a Front call can be resent after a timeout on the n8n side; our guide to webhook idempotence avoids tagging or alerting twice on the same conversation.
What the research says
Automating classification instead of leaving conversations to pile up in arrival order isn't just a team convenience: a study by S. P. Paramesh and K. S. Shreedhara, "Automated IT Service Desk Systems Using Machine Learning Techniques" (2019), published by Springer, shows on more than 10,700 real tickets that a model trained on request text reaches 89% classification accuracy, cutting resolution time and improving the end-user experience — the same principle applied here to a Front stream with an LLM instead of a purpose-trained model.
Going further
The category-based sorting and Slack alerting described here reuse the architecture already shipped in the Inbox AI Pack (€79), whose scoring and digest workflows adapt without a rewrite to a Front conversation stream instead of an isolated mailbox. For an agency centralizing several client accounts, the Complete FlowKit Bundle (€269 instead of €347) bundles every pack to cover sorting, document RAG, and audit trail in a single deployment.
FAQ
Frequently asked questions
Do I need a native Front node or the HTTP Request node?
n8n has no native Front node (n8n-nodes-base), and there is no maintained community node for this service on npm either. The HTTP Request node, combined with n8n's Webhook Trigger, is therefore the only reliable option — it works identically self-hosted and on n8n Cloud.
Rule webhook or application webhook: which one should I use?
A rule webhook is set up in a few clicks from the Front interface (Rules > Actions > Webhook) and covers nearly every sorting need. An application webhook requires building a full Front app with a handshake-based validation cycle: reserve it for a published integration meant for multiple Front accounts, not internal use.
How do I secure a Front rule webhook, which doesn't use the same signature scheme as an application webhook?
A rule webhook signs every call with an X-Front-Signature header, computed as HMAC-SHA1 over the raw request body using your API Secret — not to be confused with the HMAC-SHA256 over timestamp+body used by Front's application webhooks. Recompute that signature in a Code node before processing anything.
Bundle FlowKit Complet
€269