Automatiser avec n8n ou Make
Vérifiez les contacts qu'un autre outil garde, à intervalles réguliers : envoyez-les en un batch avec leurs identifiants, attendez-le, puis inscrivez chaque recommandation.
Un workflow n8n ou Make peut vérifier les contacts qu'un outil garde (un CRM, un outil de newsletter, un tableur, une base de données) sans exporter de fichier à la main. Il lit les contacts, envoie leurs adresses à PricklyMails en un seul batch, chacune avec l'identifiant de son contact, puis inscrit chaque recommandation sur ce contact. Côté PricklyMails, il suffit de trois requêtes, envoyées depuis le nœud HTTP de la plateforme ; les nœuds qui lisent et modifient les contacts sont ceux de l'outil, dans la documentation de la plateforme.
Avant de commencer
Créez une clé API dans le dashboard, avec les scopes email:verify:bulk et results:read (voir Clés API).
Dans n8n, enregistrez-la comme identifiant Bearer Auth, la clé seule puisque n8n ajoute Bearer lui-même, et choisissez-le dans chaque nœud HTTP Request.
Dans Make, réglez chaque module Make a request de l'application HTTP sur le type d'authentification API key, avec une clé dont la Key est Bearer pm_live_votre_cle, placée In the header sous le nom Authorization.
Ne mettez pas la clé dans Headers : l'application HTTP de Make demande les identifiants dans leur propre champ, et une valeur saisie dans Headers part avec le blueprint du scénario.
Envoyer les contacts en un seul batch
Réunissez les contacts renvoyés par l'outil dans une seule requête : emails contient leurs adresses et custom_ids, dans le même ordre, l'identifiant de chaque contact dans l'outil.
Le nœud Aggregate de n8n, ou l'Array aggregator de Make, transforme les contacts en ces deux listes.
Ici, contacts.json contient { "name": "Contacts Notion", "emails": [...], "custom_ids": [...] }, soit 20 contacts :
curl -X POST https://api.pricklymails.com/api/batches \
-H "Authorization: Bearer pm_live_votre_cle" \
-H "Content-Type: application/json" \
-d @contacts.json
{
"batch_uuid": "f6ae54c6-0fa4-474c-ab5b-f53808bb7917",
"status": "processing",
"total_jobs": 20,
"syntax_errors": 0,
"duplicates": 0,
"estimated_cost": 200
}
Un custom_id est l'identifiant du contact dans l'outil, jamais son adresse : s'il contient un @, il est refusé, et il compte au plus 256 caractères.
Une adresse mal formée, ou le doublon d'une autre, ne devient jamais une tâche : son contact n'a pas de ligne dans les résultats, et le batch la compte dans syntax_errors ou duplicates.
Un batch compte au moins 20 adresses et au plus 4 096 par requête : envoyez une liste plus longue en plusieurs fois, et vérifiez une à une les listes de moins de 20 adresses (voir « Un nouveau contact à la fois » plus bas).
Attendre la fin du batch
Un batch n'envoie pas de webhook : le workflow lit donc GET /api/batches/{uuid} jusqu'à ce que status ne soit plus processing. Il se termine completed, ou partially_completed quand certaines tâches ont échoué.
curl https://api.pricklymails.com/api/batches/f6ae54c6-0fa4-474c-ab5b-f53808bb7917 \
-H "Authorization: Bearer pm_live_votre_cle"
Dans n8n, un nœud Wait d'une minute, suivi d'un nœud If sur status dont la branche « faux » revient au nœud Wait, forme la boucle.
Un scénario Make s'exécute de son premier module à son dernier, sans revenir en arrière : le scénario qui envoie le batch garde son batch_uuid dans un Data store, et un second scénario, planifié plus tard, y relit le batch.
Inscrire chaque recommandation
GET /api/batches/{uuid}/results renvoie au plus 96 lignes par requête (limit=96) : augmentez offset jusqu'à recevoir une page plus courte que la limite.
Le nœud HTTP Request de n8n le fait avec son option Pagination (Update a Parameter in Each Request), et le module Make a request de Make avec sa pagination par décalage.
curl "https://api.pricklymails.com/api/batches/f6ae54c6-0fa4-474c-ab5b-f53808bb7917/results?limit=96&offset=0" \
-H "Authorization: Bearer pm_live_votre_cle"
{
"results": [
{
"uuid": "cc23c478-cf28-4908-acf5-cdcc58c80935",
"custom_id": "page-00",
"status": "completed",
"score": 0,
"verdict": "invalid",
"reason": "null_mx",
"recommendation": "remove"
}
],
"limit": 96,
"offset": 0
}
Le nœud Split Out de n8n, ou l'Iterator de Make, fait de chaque ligne un élément.
Le nœud de l'outil met ensuite à jour le contact dont l'identifiant est le custom_id de la ligne : remove le sort de vos envois (une désinscription, une étiquette, un retrait de la liste), review le signale pour un coup d'œil avant le prochain envoi, et send ne change rien.
Le sens de chaque recommandation est sur Batches ; où l'inscrire dans chaque outil, sur sa page d'outil.
Un nouveau contact à la fois
Pour un contact qui arrive seul (un formulaire, une inscription), le workflow se passe du batch : il envoie l'adresse à POST /api/verify avec Prefer: wait=12, et reçoit le résultat dans la même réponse quand la vérification se termine dans ces 12 secondes (voir Vérifier un email).
Laissez plus de temps que cela au nœud HTTP : réglez l'option Timeout de n8n, en millisecondes, sur 16 000 ou plus, et celle de Make, en secondes, sur 16 ou plus.
Sans résultat à temps, le workflow le lit plus tard avec GET /api/verify/{uuid} ou le reçoit sur un webhook.
La clé a alors aussi besoin du scope email:verify:single.
- HTTP Request credentials (nouvel onglet)docs.n8n.io
- HTTP Request node (nouvel onglet)docs.n8n.io
- Aggregate node (nouvel onglet)docs.n8n.io
- Loop (nouvel onglet)docs.n8n.io
- Split Out node (nouvel onglet)docs.n8n.io
- HTTP app (nouvel onglet)apps.make.com
- API key authentication type (nouvel onglet)apps.make.com
- Blueprints (nouvel onglet)help.make.com
- Flow control (nouvel onglet)help.make.com
- Data stores (nouvel onglet)help.make.com