Estou procurando migrar de Relay para n8n. Configurei meu OAuth do Hubspot E a Chave de Serviço da API no Relay e a conexão OAuth foi capaz de definir a primeira etapa como um gatilho de envio de formulário do Hubspot. Vejo que isso ainda não é possível no n8n, apesar de ter acesso à mesma infraestrutura.
Solicitação de Recurso: O evento de gatilho Envio de Formulário do Hubspot pode ser adicionado como um gatilho do Hubspot, já que claramente foi possível fazer isso no Relay?
Pedido à Comunidade: Não tenho a conta Enterprise no Hubspot necessária para uma etapa alternativa de webhook para disparar com base em envios de formulário. Também não posso disparar baseado em contato criado porque clientes existentes às vezes preenchem esses formulários do Hubspot. O Assistente de IA do n8n está me apontando para configurar uma credencial de API do Desenvolvedor do Hubspot separada. Ao gerar isso no Hubspot, recebo o token da API, mas o n8n quer o ID do aplicativo, ID do cliente, etc., que a API do Desenvolvedor não fornece. Posso adicionar essas propriedades de ID do cliente e ID do aplicativo se criar um aplicativo do Hubspot no marketplace público, mas isso não parece certo. Não quero que isso seja público de forma alguma.
Algum conselho ou ajuda aqui?
Para envios de formulários especificamente, o caminho mais limpo sem uma conta empresarial é a ferramenta de automação Workflows do plano gratuito do HubSpot: crie um fluxo de trabalho simples acionado por “Formulário enviado” e adicione uma ação Webhook apontando para a URL do seu nó Webhook n8n. Isso funciona nos planos Starter/Pro, não apenas Enterprise, e evita toda a bagunça de registro do aplicativo da API de Desenvolvedor em que você está se metendo com ID do cliente/ID do aplicativo. Você não precisa de um aplicativo de marketplace público para isso, os webhooks de fluxo de trabalho interno do HubSpot não exigem isso. Isso contorna completamente a necessidade do recurso de assinatura de webhook empresarial.
Infelizmente, a Hubspot mudou isso após lançar o Data Hub e você não pode fazer uma ação de webhook em workflows com os níveis Starter ou Pro do Sales Hub ou Marketing Hub. Talvez eu esteja perdendo algo, mas aqui é onde está explicitamente declarado na Hubspot. e novamente no topo desta página. Eu adoraria estar perdendo algo aqui 
„Enviar um webhook (Data Hub Professional e Enterprise apenas)
| Acionar um webhook para um aplicativo externo. Isso permite que seu workflow se comunique com esse aplicativo externo. Por exemplo, webhooks podem enviar as informações de uma empresa HubSpot (formatadas em JSON) para um CRM externo. Esta ação pode ser usada com todos os tipos de workflow.
Saiba mais sobre acionamento de webhooks.
1 curtida
Boa observação, essa ação agora requer Data Hub Pro. Como a ação webhook do workflow está fora, mude para polling em vez de pushing: crie um Private App do HubSpot com o escopo de formulários, depois use um n8n Schedule Trigger mais um nó HTTP Request chamando GET https://api.hubapi.com/marketing/v3/forms/{formId}/submissions com o token do Private App como autenticação Bearer. Armazene o último submittedAt ou id processado (uma Data Table ou até um simples Set/IF contra a execução anterior) para encaminhar apenas novos envios para sua etapa de CRM. Isso evita tanto o requisito do webhook Data Hub quanto o registro de aplicativo público que você estava tentando evitar. Teste o nó HTTP Request sozinho primeiro e confirme se a resposta inclui um array de resultados com timestamps submittedAt nos quais você pode filtrar.
Obrigado, é uma boa ideia. Eu poderia configurar para executar a cada 15 minutos e, com ele configurado apenas para pegar entradas novas — isso definitivamente poderia funcionar. Vou tentar isso. Valeu!
Como você vai tentar a rota de polling de 15 minutos, eu criaria um pequeno workflow com checkpoint em vez de um fluxo direto “poll → CRM”. Dessa forma, uma retentativa ou falha parcial não duplicará envios de formulário.
Uma forma viável de n8n:
- Schedule Trigger — a cada 15 minutos.
- HTTP Request: listar envios de formulário HubSpot — use um token de HubSpot Private App como
Authorization: Bearer ...; chame o endpoint de envios para o formulário específico que você se importa.
- Code: filtrar apenas novos envios — compare
submittedAt / id de envio contra um checkpoint salvo.
- Split In Batches — processe cada novo envio um de cada vez.
- CRM / etapas downstream — crie/atualize o que você estava fazendo no Relay.
- Code: salvar checkpoint apenas após sucesso — atualize o último timestamp/id processado no final, não antes da etapa CRM.
Para o nó Code de filtro/checkpoint, este é o padrão que eu usaria:
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,
},
}));
Depois que a etapa CRM downstream tiver sucesso, adicione um nó 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();
Uma armadilha: dados estáticos de workflow são salvos confiávelmente em execuções de trigger ativas, então teste o nó HTTP manualmente, mas teste o comportamento de checkpoint com o workflow ativado. Se você precisar reprocessar uma janela com falha, temporariamente limpe lastSubmittedAt ou mova-o alguns minutos para trás.
Nota transparente: construí este blueprint de polling com checkpoint com FlowForge AI e o adaptei à sua restrição HubSpot/Data Hub. O builder está aqui se você quiser gerar uma versão JSON de n8n mais completa: FlowForge AI — Build Smarter Workflows with AI
1 curtida
Se os webhooks de fluxo de trabalho do HubSpot forem bloqueados para sua conta, eu evitaria o caminho do aplicativo público para isso. Um token de aplicativo privado é suficiente para um fluxo de trabalho de polling interno.
O padrão de fallback é:
- Criar um Aplicativo Privado HubSpot com os escopos mínimos de CRM e formulários que você precisa
- No n8n, usar um Schedule Trigger em vez de um acionador HubSpot
- Usar HTTP Request com o token bearer do aplicativo privado
- Consultar envios de formulário recentes ou contatos modificados recentemente
- Filtrar pelos IDs de formulário específicos que você se importa
- Armazenar um cursor para que cada envio seja processado uma vez
- Manter uma tabela de deduplicação com chave em form_submission_id se disponível, ou em form_id mais submitted_at mais email/contact id
A parte importante é separar contato criado de formulário enviado. Você está certo que contato criado perderá contatos existentes enviando um novo formulário. Fazer polling de envios de formulário e depois deduplicar pela identidade do envio é o substituto mais seguro até que o n8n tenha um acionador nativo de envio de formulário HubSpot.
Também projetaria a primeira versão para ser executada a cada 2 a 5 minutos em vez de tentar simular um acionador verdadeiramente instantâneo. Para a maioria dos fluxos de trabalho de formulário, isso é próximo o suficiente e evita depender de uma ação de webhook HubSpot que pode desaparecer com uma mudança de plano.
Antes de construir isso, eu confirmaria:
- Quais formulários HubSpot exatos devem acionar fluxos de trabalho
- Se cada formulário é mapeado para a mesma ação downstream ou ramificações diferentes
- Qual campo comprova que um envio é novo
- Onde os IDs de envio processados devem ser armazenados no n8n
Isso oferece um fluxo de trabalho privado interno sem criar um aplicativo público de marketplace.