Connecter Front à n8n : trier et router automatiquement les conversations de l'inbox partagée

Une boîte Front partagée entre plusieurs équipes — support, ventes, opérations — centralise vite des dizaines de conversations par jour, arrivées par email, chat ou réseaux sociaux, dans une seule file sans distinction automatique entre une question basique et une demande urgente d'un client stratégique. Les règles internes de Front (Rules) couvrent des scénarios simples de tag et d'assignation par mot-clé, mais s'arrêtent là où commence la compréhension du contenu. Ce guide montre comment brancher n8n sur Front via ses Rule Webhooks et son API REST, pour classer chaque conversation entrante avec un LLM, la router vers la bonne équipe et alerter Slack sur les urgences.

Pas de node Front, ni natif ni communautaire

n8n n'a pas de node Front natif (n8n-nodes-base). Contrairement à Crisp ou Gorgias, il n'existe pas non plus de community node maintenu pour ce service sur npm — les résultats de recherche renvoient uniquement des packages sans rapport (Frontify, FrontMatter). Le node HTTP Request, combiné au Webhook Trigger de n8n, reste donc la seule voie fiable, et elle fonctionne à l'identique en self-hosted comme sur n8n Cloud ; notre guide sur les community nodes explique par ailleurs les précautions à prendre quand un tel node existe mais reste non vérifié. Si l'hébergement n'est pas encore tranché chez vous, notre comparatif self-hosted vs Cloud aide à peser ce critère.

Rule webhook ou application webhook : deux mécanismes distincts

Front propose deux façons de pousser des évènements vers une URL externe, avec des logiques de sécurité différentes :

• Rule webhook : une action ajoutée à une règle Front classique (menu Règles, structure WHEN > IF > THEN). Elle se configure en quelques clics sans rien construire côté Front au-delà de la règle elle-même — l'option la plus rapide pour un usage interne.
• Application webhook : rattaché à une app Front complète, avec activation par un handshake X-Front-Challenge et désactivation automatique après trois échecs consécutifs. Ce mécanisme cible les intégrations publiées destinées à plusieurs comptes Front, pas un usage interne — inutilement lourd pour ce guide.

Ce guide retient donc le rule webhook, largement suffisant pour trier et router les conversations d'une seule organisation.

Générer et sécuriser les identifiants API

Depuis Settings > Developers > API tokens, générez un token pour un usage interne à une seule organisation ; Front supporte aussi OAuth2, pertinent pour une agence pilotant plusieurs comptes clients depuis une même instance n8n, sur le principe déjà détaillé dans notre guide sur l'hébergement n8n pour une agence multi-clients. Chaque appel s'authentifie avec un en-tête Authorization: Bearer <token> sur l'URL de base https://api2.frontapp.com. Créez un credential n8n de type « Header Auth » plutôt que de coller le token en clair dans chaque node HTTP Request : notre guide sur la sécurisation des credentials API détaille cette pratique.

Configurer le rule webhook côté Front

Dans Règles, créez une règle avec pour déclencheur « Message reçu », sans condition restrictive si vous voulez classer l'ensemble du flux entrant, puis ajoutez l'action Webhook en pointant vers l'URL de test de votre Webhook Trigger n8n. Basculez vers l'URL de production une fois le workflow activé.

Chaque appel est signé avec un en-tête X-Front-Signature, calculé en HMAC-SHA1 sur le corps brut de la requête avec votre API Secret (visible dans les paramètres de l'organisation) — un schéma différent du HMAC-SHA256 sur timestamp:corps utilisé par les webhooks d'application Front, à ne pas confondre si vous migrez plus tard vers ce second mécanisme. Recalculez cette signature dans un node Code avant de traiter quoi que ce soit : le principe général est le même que celui détaillé dans notre guide sur la sécurisation des webhooks n8n, seule la mécanique de calcul change.

Construire le workflow de tri

Le pipeline reprend une structure déjà éprouvée sur ce blog pour la priorisation de tickets support, appliquée ici au flux Front :

1. Webhook Trigger — reçoit chaque évènement de la règle ; un node Code vérifie X-Front-Signature puis un node IF filtre les messages entrants des visiteurs, en écartant les messages internes ou déjà envoyés par un agent.
2. Node IA — envoie le contenu du message, le sujet de la conversation et le canal d'origine (email, chat, SMS, réseau social — Front les unifie tous dans une même structure de conversation) à un LLM avec une sortie structurée (urgence, catégorie, équipe cible), sur le modèle décrit dans notre guide sur le Structured Output Parser.
3. Switch — route selon la catégorie : une demande commerciale part vers l'équipe ventes via le champ inbox_id, une urgence support critique déclenche une alerte Slack sur le schéma déjà documenté pour l'approbation humaine via Slack, le reste est simplement tagué et assigné pour rester traçable dans Front.

Taguer, assigner et déplacer via l'API REST

Un seul appel couvre l'essentiel du tri : PATCH /conversations/{conversation_id} accepte tag_ids (remplace les tags de la conversation), assignee_id (assigne à un teammate précis) et inbox_id (déplace la conversation vers une autre boîte), avec une réponse 204 sans corps à la clé. Ce même endpoint suffit donc à la fois pour un tri silencieux (tag seul) et pour un routage complet (tag + assignation + déplacement) en un unique appel plutôt que trois.

Front applique un quota par organisation, pas par token : 50 requêtes par minute sur le plan Starter, 100 sur Professional, 200 sur Enterprise, avec un plafond distinct de 120 requêtes par minute pour les intégrations OAuth partenaires. S'y ajoutent des plafonds par ressource et par seconde — 5 requêtes/seconde pour les conversations, messages et canaux, 1 requête/seconde pour les exports — un budget à surveiller comme n'importe quel quota d'API décrit dans notre guide sur le rate limiting des API IA, particulièrement si d'autres outils (CRM, reporting) partagent la même organisation Front.

Cas d'usage concrets

• Agence gérant plusieurs marques : une seule règle Front, un seul workflow n8n paramétré par inbox_id, pour trier les conversations de plusieurs canaux clients à la fois — la même logique de mutualisation que celle décrite dans notre guide sur l'hébergement n8n pour une agence multi-clients.
• Boîte commerciale partagée : une demande entrante contenant un signal d'intention d'achat est taguée et assignée directement au commercial du secteur concerné, sur le principe déjà détaillé dans notre guide sur la qualification des leads entrants par IA.
• Support multicanal : une conversation arrivée par SMS ou réseau social suit le même pipeline de classification qu'un email, puisque Front les unifie dans une structure de conversation commune — l'intérêt principal de router depuis Front plutôt que depuis chaque canal pris séparément.

Pièges à éviter

• Confondre les deux schémas de signature : un code de vérification écrit pour un webhook d'application (HMAC-SHA256 sur timestamp+corps) échoue silencieusement sur un rule webhook (HMAC-SHA1 sur le corps seul), et inversement.
• Ignorer que le quota est partagé par organisation : un pic de tags en masse déclenché par n8n peut priver d'autres outils connectés au même compte Front de leur marge d'appels ; répartir les traitements en masse dans le temps évite ce conflit.
• Traiter les messages sortants comme des messages entrants : sans filtre sur l'expéditeur, une réponse d'agent redéclenche inutilement le workflow — vérifiez systématiquement le rôle de l'expéditeur avant de classer quoi que ce soit.
• Ne pas gérer les retries : comme tout webhook, un appel Front peut être renvoyé après un timeout côté n8n ; notre guide sur l'idempotence des webhooks évite de taguer ou d'alerter deux fois la même conversation.

Ce que dit la recherche

Automatiser la classification plutôt que de laisser les conversations s'empiler dans l'ordre d'arrivée n'est pas qu'un confort d'équipe : une étude de S. P. Paramesh et K. S. Shreedhara, « Automated IT Service Desk Systems Using Machine Learning Techniques » (2019), publiée chez Springer, montre sur plus de 10 700 tickets réels qu'un modèle entraîné sur le texte des demandes atteint 89 % de précision de classification, avec à la clé une réduction du temps de résolution et une meilleure expérience côté utilisateur final — le même principe appliqué ici à un flux Front avec un LLM plutôt qu'un modèle entraîné sur mesure.

Pour aller plus loin

Le tri par catégorie et l'alerte Slack décrits ici reprennent l'architecture déjà livrée dans le Pack Inbox IA (79 €), dont les workflows de scoring et de digest s'adaptent sans réécriture à un flux de conversations Front plutôt qu'à une boîte mail isolée. Pour une agence qui centralise plusieurs comptes clients, le Bundle FlowKit Complet (269 € au lieu de 347 €) réunit l'ensemble des packs pour couvrir tri, RAG documentaire et piste d'audit en un seul déploiement.