Zapier et automatisation CRM

MailInApp n'a pas encore d'application Zapier officielle, mais vous n'en avez pas besoin. Le webhook de projet est déjà du JSON signé, brut, via HTTPS — exactement ce qu'attend le déclencheur générique Webhooks by Zapier de Zapier. Pointez-le vers n'importe quel Zap et chaque interaction — vote de sondage, soumission de formulaire, résultat de quiz, achat de produit — arrive dans votre CRM, une feuille de calcul, Slack, ou partout ailleurs où Zapier peut accéder, sans code.

La même approche fonctionne avec Make, n8n, Pipedream, ou tout autre outil d'automatisation capable de capter un webhook entrant — ce guide utilise Zapier car c'est l'outil le plus fréquemment demandé.

Configuration

1. Dans Zapier, créez un nouveau Zap et choisissez Webhooks by Zapier comme application de déclenchement, avec l'événement Catch Hook.
2. Zapier vous donne une Catch Hook URL unique — copiez-la.
3. Dans MailInApp, ouvrez Dashboard → votre email → Responses, collez cette URL dans le champ Webhook, et cliquez sur Enable.
4. Copiez le secret de signature que MailInApp vous affiche (whsec_…) — vous ne le verrez qu'une seule fois. Vous n'en avez pas besoin pour les Zaps les plus simples, mais conservez-le en lieu sûr si vous prévoyez de vérifier les signatures plus tard.
5. Déclenchez une interaction réelle — votez sur un sondage, soumettez un formulaire, ou utilisez l'envoi de test du projet — puis cliquez sur Test trigger dans Zapier. Cela devrait afficher la charge utile que MailInApp vient d'envoyer, avec des champs comme event.action, event.value, et recipient.row.
6. Ajoutez l'étape d'action de votre choix — « Create row in Google Sheets », « Create record in HubSpot/Salesforce/Airtable », « Send Slack message », etc. — en associant les champs dont vous avez besoin depuis la charge utile captée.
7. Activez le Zap.

C'est tout — chaque future interaction sur ce projet remonte automatiquement. Tous les champs disponibles pour l'association sont documentés dans la référence de la charge utile des webhooks.

Filtrer ce qui compte

La plupart des cas d'usage CRM ne s'intéressent qu'à certaines interactions — un formulaire complété, pas chaque ouverture. Ajoutez une étape Filter by Zapier juste après le déclencheur :

• Ne continuez que si event.action correspond exactement à submit (ou vote, rate, purchase, etc.) pour réagir à une action spécifique.
• Ne continuez que si event.blockId correspond exactement à l'id d'un bloc spécifique (visible dans l'inspecteur de blocs du studio) pour réagir à un bloc spécifique, en ignorant les autres du même projet.
• Ne continuez que si lowScore vaut true pour construire un Zap d'alerte aux managers pour les mauvaises réponses CSAT/NPS — le même signal qu'utilisent les alertes de score faible intégrées propres à MailInApp, mais acheminé via votre propre automatisation.

Renvoyer des contacts dans l'autre sens

L'automatisation fonctionne généralement dans les deux sens : un ticket de support se résout, et vous voulez que cette personne soit ajoutée (ou mise à jour) dans une liste de contacts MailInApp pour un envoi de suivi, sans qu'un humain n'ait à réexporter un CSV. Utilisez une étape d'action Webhooks by Zapier → POST comme dernière étape de n'importe quel Zap — « ticket résolu », « affaire conclue », « formulaire soumis ailleurs » — pointée vers l'endpoint d'upsert de lignes de votre liste de contacts pour tenir automatiquement à jour une liste d'envoi MailInApp. Cet endpoint accepte jusqu'à 500 lignes par appel et est limité à 30 requêtes par minute par clé API. C'est généreux pour un Zap se déclenchant sur des événements individuels, mais bon à savoir si vous faites un jour transiter une grosse récupération en lot par ce biais.

En cas d'échec de livraison

Une URL de Zap morte, un Zap en pause, ou une panne temporaire de Zapier comptent tous comme un échec de livraison du côté de MailInApp. C'est aussi le cas d'une URL de réception qui répond par une redirection plutôt qu'une réponse normale — MailInApp ne suit pas les redirections lors de la livraison des webhooks. Une livraison simplement trop lente échoue aussi : elle dispose de 5 secondes pour répondre avant que MailInApp ne la considère comme échouée. Les livraisons sont retentées automatiquement avec un backoff, et toute livraison encore en échec apparaît sous Failed deliveries sur la page Responses avec un bouton manuel Redeliver — voir la sémantique de livraison pour le calendrier complet des tentatives. Rien n'est jamais silencieusement abandonné : l'interaction elle-même est toujours stockée dans MailInApp en premier, que la livraison du webhook réussisse ou non.