Je cherche à passer de Relay à n8n. J’ai configuré mon OAuth HubSpot ET ma clé de service API dans Relay et la connexion OAuth a permis de définir la première étape comme déclencheur de soumission de formulaire HubSpot. Je vois que ce n’est pas encore possible dans n8n alors qu’il a accès à la même infrastructure exacte.
Demande de fonctionnalité : Pourriez-vous ajouter l’événement déclencheur Form Submission de HubSpot en tant que déclencheur HubSpot puisqu’il a clairement été rendu possible dans Relay ?
Appel à la communauté : Je n’ai pas le compte entreprise dans HubSpot nécessaire pour une étape webhook alternative permettant de déclencher en fonction des soumissions de formulaires. De plus, je ne peux pas déclencher à partir de « contact créé » car les clients existants complètent parfois ces formulaires HubSpot. L’assistant IA n’8n me suggère de configurer une credential API Developer HubSpot distincte. Lors de sa génération dans HubSpot, j’obtiens le token API mais n8n demande l’ID d’application, l’ID client, etc., que l’API Developer ne fournit pas. Je peux faire ajouter ces propriétés d’ID client et d’ID d’application si je crée une application HubSpot sur le marketplace public, mais cela ne semble pas approprié. Je ne veux pas que cela soit public de quelque manière que ce soit.
Avez-vous des conseils ou de l’aide à ce sujet ?
Pour les soumissions de formulaires spécifiquement, le chemin le plus simple sans compte entreprise est l’outil d’automatisation Workflows de la couche gratuite de HubSpot : créez un simple workflow déclenché par « Form submitted » (Formulaire soumis), puis ajoutez une action Webhook pointant vers l’URL de votre nœud Webhook n8n. Cela fonctionne sur les tiers Starter/Pro, pas seulement Enterprise, et vous évite tout le désordre de l’enregistrement des applications Developer API auquel vous êtes confronté avec les identifiants client/app ID. Vous n’avez pas besoin d’une application de marketplace publique pour cela, les webhooks de workflow internes de HubSpot ne l’exigent pas. Cela contourne complètement le besoin de la fonctionnalité de souscription webhook entreprise.
Malheureusement, Hubspot a modifié cela après le lancement de Data Hub et vous ne pouvez pas effectuer une action webhook dans les workflows avec les niveaux Starter ou Pro de Sales Hub ou Marketing Hub. Je ne sais peut-être pas tout, mais voici où c’est explicitement indiqué dans Hubspot. et à nouveau en haut de cette page. J’aimerais bien me tromper cependant 
« Envoyer un webhook (Data Hub Professional et Enterprise uniquement)
Déclencher un webhook vers une application externe. Cela permet à votre workflow de communiquer avec cette application externe. Par exemple, les webhooks peuvent envoyer les informations d’une entreprise HubSpot (formatées en JSON) à un CRM externe. Cette action peut être utilisée avec tous les types de workflows.
En savoir plus sur le déclenchement des webhooks. » |
1 « J'aime »
Bonne remarque, cette action nécessite maintenant Data Hub Pro. Puisque l’action de webhook de flux est obsolète, basculez vers l’interrogation au lieu du push : créez une application privée HubSpot avec l’étendue des formulaires, puis utilisez un déclencheur de planification n8n plus un nœud HTTP Request appelant GET https://api.hubapi.com/marketing/v3/forms/{formId}/submissions avec le jeton de l’application privée comme authentification Bearer. Stockez le dernier submittedAt ou id traité (une table de données ou même un simple Set/IF par rapport à l’exécution précédente) afin de ne transférer que les nouveaux envois à votre étape CRM. Cela évite à la fois l’exigence du webhook Data Hub et l’enregistrement d’application publique que vous tentiez d’éviter. Testez d’abord le nœud HTTP Request seul et confirmez que la réponse inclut un tableau de résultats avec des horodatages submittedAt sur lesquels vous pouvez filtrer.
Merci, c’est une bonne idée. Je pourrais le configurer pour s’exécuter toutes les 15 minutes et, avec la restriction de ne récupérer que les nouvelles entrées — ça pourrait vraiment fonctionner. Je vais essayer. Merci !
Puisque tu vas essayer la route de sondage toutes les 15 minutes, je ferais plutôt un petit workflow avec checkpoint qu’un flux direct « sondage → CRM ». De cette façon, une nouvelle tentative ou une défaillance partielle ne dupliquera pas les soumissions de formulaire.
Une structure n8n fonctionnelle :
- Schedule Trigger — toutes les 15 minutes.
- HTTP Request: list HubSpot form submissions — utilise un jeton Private App HubSpot en tant que
Authorization: Bearer ... ; appelle l’endpoint des soumissions pour le formulaire spécifique qui t’intéresse.
- Code: filter only new submissions — compare
submittedAt / l’id de soumission par rapport à un checkpoint sauvegardé.
- Split In Batches — traite chaque nouvelle soumission une à la fois.
- CRM / downstream steps — crée/mets à jour ce que tu faisais dans Relay.
- Code: save checkpoint only after success — mets à jour le timestamp/l’id le plus récent traité à la fin, pas avant l’étape CRM.
Pour le nœud Code filter/checkpoint, voici le motif que j’utiliserais :
const staticData = $getWorkflowStaticData('global');
const lastSubmittedAt = staticData.lastSubmittedAt || '1970-01-01T00:00:00.000Z';
const submissions = $json.results || [];
const fresh = submissions
.filter((submission) => new Date(submission.submittedAt) > new Date(lastSubmittedAt))
.sort((a, b) => new Date(a.submittedAt) - new Date(b.submittedAt));
return fresh.map((submission) => ({
json: {
hubspotSubmissionId: submission.id || submission.submissionId,
submittedAt: submission.submittedAt,
formId: submission.formId,
fields: submission.values || submission.submittedValues || [],
raw: submission,
},
}));
Ensuite, après que l’étape CRM en aval réussisse, ajoute un nœud Code final :
const staticData = $getWorkflowStaticData('global');
const newest = $input.all()
.map((item) => item.json.submittedAt)
.filter(Boolean)
.sort()
.at(-1);
if (newest) staticData.lastSubmittedAt = newest;
return $input.all();
Une chose à retenir : les données statiques du workflow sont sauvegardées de manière fiable lors des exécutions de déclencheur actif, donc teste le nœud HTTP manuellement, mais teste le comportement du checkpoint avec le workflow activé. Si tu dois retraiter une fenêtre défaillante, efface temporairement lastSubmittedAt ou recule-le de quelques minutes.
Note de transparence : j’ai construit ce blueprint de sondage avec checkpoint avec FlowForge AI et l’ai adapté à ta contrainte HubSpot/Data Hub. Le générateur est ici si tu veux générer une version n8n JSON plus complète : FlowForge AI — Build Smarter Workflows with AI
1 « J'aime »
Si les webhooks de workflow HubSpot sont restreints pour votre compte, j’éviterais le chemin de l’application publique pour cela. Un jeton d’application privée suffit pour un workflow d’interrogation interne.
Le modèle de secours est :
- Créer une application privée HubSpot avec les portées CRM et formulaires minimales dont vous avez besoin
- Dans n8n, utiliser un déclencheur Schedule au lieu d’un déclencheur HubSpot
- Utiliser HTTP Request avec le jeton bearer de l’application privée
- Interroger les soumissions de formulaires récentes ou les contacts récemment modifiés
- Filtrer les ID de formulaire spécifiques qui vous intéressent
- Stocker un curseur pour que chaque soumission soit traitée une seule fois
- Conserver une table de dédoublonnage indexée par form_submission_id si disponible, ou par form_id plus submitted_at plus email/contact id
La partie importante est de séparer la création de contact de la soumission de formulaire. Vous avez raison que la création de contact manquera les contacts existants soumettant un nouveau formulaire. L’interrogation des soumissions de formulaires, puis le dédoublonnage par identité de soumission, est le substitut plus sûr jusqu’à ce que n8n dispose d’un déclencheur de soumission de formulaire HubSpot natif.
Je concevrais également la première version pour s’exécuter toutes les 2 à 5 minutes au lieu d’essayer de simuler un vrai déclencheur instantané. Pour la plupart des workflows de formulaire, c’est suffisamment proche, et cela évite de dépendre d’une action webhook HubSpot qui pourrait disparaître lors d’un changement de plan.
Avant de le construire, je confirmerais :
- Quels formulaires HubSpot exacts doivent déclencher des workflows
- Si chaque formulaire correspond à la même action en aval ou à des branches différentes
- Quel champ prouve qu’une soumission est nouvelle
- Où les ID de soumission traités doivent être stockés dans n8n
Cela vous donne un workflow privé interne sans créer d’application marketplace publique.