Connecter Gorgias à n8n : trier et router automatiquement les tickets support e-commerce

Un site e-commerce qui tourne avec Gorgias reçoit ses tickets depuis plusieurs canaux à la fois — email, chat, réseaux sociaux, téléphone — tous fusionnés dans une même vue, sans distinction native entre une question de taille de vêtement et une demande de remboursement urgente pour un client mécontent. Gorgias propose bien son propre module d'IA (Gorgias Automate) pour trier et répondre automatiquement, mais facturé au ticket résolu par l'IA, avec une logique fermée que vous ne contrôlez pas. Ce guide montre comment brancher n8n sur Gorgias via ses HTTP Integrations (l'équivalent maison des webhooks) et son API REST, pour classer chaque ticket entrant, le tagger et router les urgences vers Slack, sans dépendre du module IA propriétaire de Gorgias.

Deux façons de brancher Gorgias sur n8n

n8n n'a pas de node Gorgias natif (n8n-nodes-base). Il existe un community node publié sur npm, mais sans badge « verified » : installable uniquement depuis Settings > Community Nodes sur une instance self-hosted, indisponible sur n8n Cloud — notre guide sur les community nodes détaille cette distinction et les précautions à prendre avant d'en installer un.

Ce guide prend donc le chemin qui fonctionne partout, self-hosted comme Cloud, et qui reste le plus simple à auditer dans la durée : un Webhook Trigger pour recevoir les évènements Gorgias, et le node HTTP Request pour appeler l'API REST en retour. Si l'hébergement n'est pas encore tranché chez vous, notre comparatif self-hosted vs Cloud aide à peser ce critère face aux autres.

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

L'API Gorgias s'authentifie en HTTP Basic : votre email de compte comme identifiant, votre clé API (générée depuis les paramètres du compte) comme mot de passe, sur une URL de base au format https://votre-domaine.gorgias.com/api. Créez un credential n8n de type « Header Auth » avec la paire encodée en base64 plutôt que de coller la clé en clair dans chaque node HTTP Request : notre guide sur la sécurisation des credentials API détaille cette pratique, valable pour n'importe quel service tiers appelé sans node dédié.

Configurer l'intégration HTTP côté Gorgias

Dans Settings > HTTP Integrations de votre compte, cliquez sur « Add HTTP Integration », donnez-lui un nom explicite, puis sélectionnez le ou les évènements déclencheurs : Ticket created pour un nouveau ticket, Ticket message created pour réagir aussi quand un client relance un ticket existant — c'est ce second évènement qu'il vaut mieux cocher pour un tri qui couvre l'intégralité du flux entrant. Collez l'URL de test de votre Webhook Trigger n8n pour valider la réception, puis remplacez-la par l'URL de production une fois le workflow activé.

Contrairement à Crisp, dont les webhooks sont signés en HMAC, la documentation Gorgias ne détaille pas de mécanisme de signature équivalent pour ses HTTP Integrations. La configuration permet en revanche d'ajouter des en-têtes personnalisés à chaque appel sortant : définissez-y un en-tête avec un secret partagé, et vérifiez sa valeur dans un node IF 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 vérification 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 multicanal de Gorgias :

1. Webhook Trigger — reçoit chaque évènement ticket_message_created ; un node IF vérifie l'en-tête secret puis filtre sender.role === "customer" pour ignorer les messages internes ou envoyés par un agent.
2. Node IA — envoie le contenu du message, plus le sujet et le canal d'origine du ticket, à un LLM avec une sortie structurée (urgence, catégorie, résumé en une phrase), sur le modèle décrit dans notre guide sur le Structured Output Parser.
3. Switch — route selon l'urgence : un ticket classé critique part vers Slack, sur le schéma déjà documenté pour l'approbation humaine via Slack ; les autres sont simplement tagués pour que l'équipe support les retrouve triés dans Gorgias.

Tagger et interroger les tickets via l'API REST

Pour tagger silencieusement un ticket sans notifier le client — l'action la plus courante pour un tri automatique — un appel PUT sur /api/tickets/{ticket_id}/tags avec un tableau tags (par exemple [{"name": "remboursement"}, {"name": "urgent"}]) suffit ; Gorgias répond 202 sans corps, sans qu'il soit nécessaire de lire une réponse pour confirmer l'opération.

Pour un digest nocturne ou un rapport hebdomadaire qui relit l'ensemble des tickets d'une période, l'endpoint GET /api/tickets utilise une pagination par curseur, avec une limite par défaut de 30 résultats et un maximum de 100 : passer explicitement limit=100 divise par plus de trois le nombre d'appels nécessaires pour parcourir un même volume, un principe détaillé dans notre guide sur la pagination avec le node HTTP Request. Gorgias expose aussi un en-tête X-Gorgias-Account-Api-Call-Limit (au format utilisé/limite) et un en-tête Retry-After en cas de 429 — un budget partagé par l'ensemble des outils connectés à votre compte, à surveiller comme n'importe quel quota d'API décrit dans notre guide sur le rate limiting des API IA.

Cas d'usage concrets

• Retours et remboursements : un message contenant « remboursement », « colis endommagé » ou un numéro de commande est tagué et route vers le workflow déjà documenté dans notre guide sur l'automatisation des retours e-commerce, plutôt que d'attendre son tour dans la file générale.
• Litiges et chargebacks : un ticket mentionnant une contestation bancaire alimente le même processus de traçabilité que notre guide sur la gestion des chargebacks Stripe, avec l'historique de conversation Gorgias joint comme preuve.
• Rupture de stock : avant de répondre à un ticket sur la disponibilité d'un produit, le workflow peut interroger en direct les niveaux de stock synchronisés via notre guide sur la synchronisation des stocks Shopify, pour tagger le ticket avec un statut « en attente de réassort » plutôt qu'une réponse générique.

Pièges à éviter

• Interroger l'API en polling plutôt qu'en webhook : chaque appel GET /api/tickets consomme le quota partagé du compte, alors qu'un évènement poussé par une HTTP Integration ne coûte rien — privilégiez toujours le webhook pour tout ce qui est temps réel.
• Ignorer les en-têtes de rate limit : sur un compte avec plusieurs intégrations actives (Gorgias Automate, un CRM, n8n), le budget d'appels se partage entre tous ; un pic de tags en masse peut déclencher des 429 si rien ne lit Retry-After.
• Ne pas gérer les retries : comme tout webhook, un appel Gorgias peut être renvoyé après un timeout côté n8n ; notre guide sur l'idempotence des webhooks évite de tagger ou d'alerter deux fois le même ticket.
• Laisser le secret d'en-tête en clair dans le workflow : stockez-le comme n'importe quel credential n8n plutôt que codé en dur dans un node IF, pour pouvoir le faire tourner sans republier le workflow.

Ce que dit la recherche

Automatiser la classification des tickets plutôt que de les laisser 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 SVM entraîné sur le texte des tickets atteint 89 % de précision de classification, loin devant un tri manuel à l'ordre d'arrivée — le même principe appliqué ici avec un LLM plutôt qu'un modèle entraîné sur mesure. Sur l'automatisation elle-même, une étude d'Ahmed Raza Amir et Syed Muhammad Atif, « Evaluating Workflow Automation Efficiency Using n8n: A Small-Scale Business Case Study » (2026), mesure sur un pipeline de notification comparable un temps d'exécution divisé par plus de 150 par rapport à un traitement manuel équivalent, avec un taux d'erreur observé passant de 5 % à zéro — le type de gain attendu ici sur un flux de tickets à volume soutenu.

Pour aller plus loin

Le tri par urgence 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 tickets Gorgias plutôt qu'à une boîte mail. Si votre priorité est plutôt de documenter et prouver votre conformité sur ce type de traitement, le Pack Conformité & Audit (149 €) couvre la piste d'audit correspondante, et le Bundle FlowKit Complet (269 € au lieu de 347 €) réunit l'ensemble pour qui veut couvrir les deux besoins d'un coup.