CRM para infoproduto: integração Hotmart e ActiveCampaign

Por que o CRM do seu infoproduto não sabe que você vendeu

Integrar Hotmart com ActiveCampaign via ListBoss resolve o problema de raiz: a compra aprovada dispara um evento em tempo real, o ListBoss recebe o payload, mapeia os campos e cria ou atualiza o contato no CRM com tag de produto e valor da venda, sem planilha, sem processo manual, sem delay.

Resumo rápido: A stack Hotmart → ListBoss → ActiveCampaign + DataCrazy elimina a importação manual de dados de venda, viabiliza onboarding automático, upsell baseado em histórico de compra e cálculo de LTV real. Quando a lógica de roteamento passa do trivial, o n8n entra como alternativa ao ListBoss. E se você quiser trocar ActiveCampaign e DataCrazy por uma peça só, a WeSales cobre CRM e WhatsApp no mesmo lugar. O ponto crítico, em qualquer arranjo: compra recusada precisa de tratamento separado ou contamina a base de clientes.

Neste post:

• Considerando as duas seções novas e a mudança de foco para o ListBoss:

  Neste post

  • O problema real da planilha semanal

  • Como o webhook da Hotmart funciona na prática

  • Arquitetura: Hotmart → ListBoss → ActiveCampaign + DataCrazy

  • Quando usar ListBoss ou n8n para integrar a Hotmart com o CRM

  • A opção de consolidar tudo na WeSales

  • O que fazer com cada evento da Hotmart

  • Eventos de uso: o que acontece depois da compra

  • A armadilha da compra recusada

  • O que fica possível depois que a integração está rodando

  • LGPD nessa stack

  • Perguntas frequentes

O problema da planilha semanal

Todo produtor digital chega num ponto parecido. As vendas estão acontecendo na Hotmart, o funil de marketing roda no ActiveCampaign, e os dois sistemas não conversam. O time de operações resolve isso da forma mais óbvia disponível: exporta o relatório de vendas toda semana, formata a planilha, importa os contatos no CRM. Funciona. Mas funciona mal.

Quando um lead compra na segunda-feira, ele passa os próximos seis dias sem receber onboarding, sem entrar no fluxo de upsell, sem nenhuma comunicação estruturada. O time de CS não sabe que ele comprou. O vendedor no WhatsApp não tem contexto. E o CRM mostra esse contato como lead ativo no pipeline de vendas, ainda sendo trabalhado, mesmo depois da compra ter sido concluída.

Esse gap entre a venda acontecer e o CRM saber que ela aconteceu é onde o dinheiro vaza. Não é exagero. É onde o LTV fica invisível, onde o upsell não é acionado, onde o cliente que comprou três produtos aparece como se tivesse comprado um.

Com o volume que a Hotmart processa no Brasil, a importação manual não é só ineficiente. É inviável como modelo de operação para qualquer negócio que queira crescer com alguma previsibilidade.

Configurando o webhook na Hotmart

Webhook é, tecnicamente, uma requisição HTTP que um sistema envia a outro quando algo acontece. No caso da Hotmart, ela dispara essa requisição automaticamente para uma URL que você configura, toda vez que um evento ocorre na plataforma.

A Hotmart oferece granularidade real nos eventos disponíveis. Você consegue escolher exatamente o que quer receber: COMPRA_APROVADA, COMPRA_COMPLETA, COMPRA_CANCELADA, COMPRA_REEMBOLSADA, CHARGEBACK, COMPRA_ATRASADA e eventos de assinatura como cancelamento e troca de plano. Essa lista importa, e vou voltar a ela mais adiante, porque selecionar os eventos errados é o ponto onde a maioria das integrações quebra de forma silenciosa.

A configuração é feita dentro do painel da plataforma, na seção de ferramentas do produto. Você insere a URL que vai receber os dados, seleciona os eventos de interesse e a Hotmart começa a enviar o payload JSON automaticamente a cada ocorrência. O payload inclui email do comprador, nome, produto, valor da venda, moeda, ID da transação e data. Tudo o que o CRM precisa para criar ou atualizar um contato com precisão.

O que a Hotmart não faz é tratar ou rotear esses dados. Ela envia. Quem recebe, interpreta e decide o que fazer com cada evento é a camada do meio.

Arquitetura: Hotmart → ListBoss → ActiveCampaign + DataCrazy

Essa é a stack padrão, e a razão de ela ser padrão é simples: cada peça faz uma coisa só, e nenhuma delas exige que você mantenha infraestrutura própria.

Hotmart: a fonte de eventos. A Hotmart processa o checkout, confirma o pagamento e dispara o webhook. Sua responsabilidade termina aí. O webhook precisa estar configurado na versão 2.0 da plataforma, vinculado ao produto específico e com os eventos corretos selecionados. Para alimentar o CRM com clientes reais, o filtro é COMPRA_APROVADA e COMPRA_COMPLETA. Nada além disso nessa URL.

ListBoss: o roteador. O ListBoss foi construído exatamente para essa ponte. Você conecta a conta da Hotmart, conecta a conta do ActiveCampaign e define as regras dentro da própria interface: qual produto gera qual tag, qual evento cria contato, qual evento remove tag, para qual lista o contato vai. Não tem código, não tem servidor para manter, não tem instância caindo às três da manhã.

O mapeamento de campos customizados também acontece ali. Valor da venda vai para um campo numérico, data da compra para um campo de data, nome do produto vira tag. Esses três campos são o mínimo para conseguir segmentar a base depois, calcular LTV e acionar upsell baseado em histórico real.

O ListBoss mantém o histórico de execuções na própria plataforma, então quando algo não chega no ActiveCampaign você tem onde olhar. Essa visibilidade costuma ser subestimada até o dia em que uma venda some.

ActiveCampaign: o CRM que recebe. O ActiveCampaign recebe o contato formatado, aplica as tags e entra na automação de onboarding correspondente ao produto comprado. A lógica é direta: cada produto tem uma automação própria, acionada pela tag correspondente. Quem comprou o produto A entra no fluxo A. Quem comprou o produto B entra no fluxo B. Sem cruzamento, sem ambiguidade.

Campos customizados de deal permitem registrar o valor da venda como campo financeiro. Isso é o que viabiliza o cálculo de LTV dentro do próprio CRM, sem depender de exportação ou de cruzar dados manualmente em planilha.

DataCrazy: vendas via WhatsApp com contexto. O DataCrazy entra como camada de comunicação ativa, especialmente para o time de vendas que opera via WhatsApp. E aqui vale registrar um ponto que muita gente não sabe: o DataCrazy recebe webhook nativo da Hotmart. Você não precisa de camada intermediária para isso.

Na prática, você cadastra uma segunda URL de webhook direto no painel da Hotmart, apontando para o DataCrazy, com os mesmos eventos de compra aprovada. A Hotmart passa a disparar para os dois destinos em paralelo: ListBoss alimenta o ActiveCampaign, DataCrazy alimenta o WhatsApp. São dois caminhos independentes saindo da mesma fonte, e nenhum depende do outro para funcionar.

O resultado é que o vendedor abre o contato no DataCrazy e já sabe o histórico de compra antes de digitar a primeira mensagem. Isso muda completamente a qualidade da conversa de upsell. O vendedor não pergunta "o que você já comprou conosco?" porque o sistema já respondeu essa pergunta antes dele perguntar. E para mensagem de boas-vindas automática logo após a compra, o próprio DataCrazy dispara a partir do evento recebido, em segundos, não em dias.

Quando o n8n faz mais sentido que o ListBoss

O ListBoss resolve muito bem o caso em que a regra é "evento X gera ação Y". A hora de trocar por n8n é quando você para de pensar em integração e começa a pensar em infraestrutura.

O primeiro sinal é volume de produtos. Se você tem quinze produtos na Hotmart e cada um precisa de tag própria, automação própria e campo próprio, configurar isso peça por peça vira um trabalho que se repete a cada lançamento. No n8n você monta uma vez a lógica que lê o ID do produto no payload e resolve o roteamento sozinha. Produto novo entra numa tabela de mapeamento, não num fluxo novo. A operação escala sem que o esforço de configuração escale junto.

O segundo sinal, e esse é o que costuma pesar mais, é a questão de estar preso ao CRM. Quando a integração vive dentro de uma ferramenta que só fala com o ActiveCampaign, trocar de CRM significa refazer tudo. Toda a lógica de roteamento, todo o mapeamento de campo, todo o tratamento de evento, tudo é reconstruído do zero na ferramenta nova, e enquanto isso a operação fica parada.

Com o n8n a camada de integração é sua. A Hotmart continua apontando para o mesmo lugar, a lógica de tratamento do payload continua igual, e o que muda é o nó final que faz a chamada de API. Você troca o node do ActiveCampaign pelo do HubSpot, pelo do Kommo, pelo do que for, remapeia os campos de destino e o resto continua de pé. Migração de CRM deixa de ser um projeto de meses e vira uma troca de destino.

Isso vale também para múltiplas plataformas de checkout. Hotmart, Kiwify e Eduzz mandam payloads em formatos diferentes. No n8n você normaliza os três para um formato interno único e daí para frente tudo é o mesmo fluxo. Plataforma nova é um tradutor a mais na entrada, não uma stack paralela.

O custo dessa liberdade é real e vale dizer com todas as letras: você passa a ser responsável pela instância. Se o n8n cai, o webhook se perde. Log de execução deixa de ser conveniência e vira obrigação. Alerta de falha também. É uma troca legítima quando você tem catálogo grande ou pretende revisar sua stack de CRM em algum momento. É trabalho desnecessário quando você tem dois produtos e nenhuma intenção de sair do ActiveCampaign.

E ajusto a menção correspondente no FAQ:

Preciso do n8n para integrar Hotmart com ActiveCampaign?

Não. O ListBoss faz essa ponte de forma nativa, com interface visual, sem servidor para manter. O n8n compensa quando você tem muitos produtos para integrar de uma vez, ou quando não quer que a camada de integração fique presa ao CRM. Com o n8n, trocar de CRM significa trocar o nó final do fluxo. Com integração nativa, significa reconstruir tudo na ferramenta nova.

A opção de consolidar tudo na WeSales

Existe um terceiro arranjo, e ele não é uma variação dos anteriores. É uma decisão diferente.

A WeSales substitui ActiveCampaign e DataCrazy ao mesmo tempo. Ela é CRM e canal de WhatsApp na mesma ferramenta, o que significa que a stack inteira encolhe para Hotmart → WeSales. Webhook nativo, sem ListBoss, sem n8n, sem camada de roteamento.

A vantagem é evidente. Uma ferramenta a menos para pagar, uma integração a menos para quebrar, um lugar só para o time olhar. O contato que comprou aparece no mesmo sistema onde o vendedor conversa com ele, e a automação de onboarding roda ali dentro.

A contrapartida também é evidente. Você troca a profundidade de automação de email do ActiveCampaign pela conveniência de ter tudo junto. Se sua operação depende de sequências longas, segmentação sofisticada por comportamento de abertura e clique, ou lógica de scoring, você vai sentir falta. Se o peso da sua operação está no WhatsApp e o email é complementar, a WeSales resolve com menos peças móveis.

Não existe resposta certa aqui. Existe alinhamento entre onde está o volume da sua operação e onde está a profundidade da ferramenta.

O que fazer com cada evento da Hotmart

A decisão de quais eventos cadastrar em qual webhook define a saúde de toda a operação, e ela é idêntica em qualquer um dos três arranjos.

Para o fluxo de clientes: COMPRA_APROVADA e COMPRA_COMPLETA apontam para a URL que alimenta o CRM. Só esses dois. Boleto emitido, Pix aguardando e compra em análise não entram nessa URL.

Para recuperação de carrinho: um webhook separado, com URL diferente, captura o evento de carrinho abandonado. Esse fluxo cria contato com tag de "carrinho abandonado" e aciona sequência de follow-up. É um pipeline paralelo, não o mesmo de clientes confirmados.

Para cancelamentos e reembolsos: um terceiro webhook trata COMPRA_CANCELADA, COMPRA_REEMBOLSADA e CHARGEBACK. Esse fluxo remove a tag de produto ativo, atualiza o status do contato e pode acionar o time de CS. O contato não sai do CRM, mas o contexto muda.

Três URLs, três fluxos, três propósitos. Misturar tudo em um webhook único é a receita para base contaminada.

O que fazer com cada evento da Hotmart

A decisão de quais eventos cadastrar em qual webhook define a saúde de toda a operação, e ela é idêntica em qualquer um dos três arranjos.

Para o fluxo de clientes: PURCHASE_APPROVED é o evento que alimenta o CRM. Ele dispara no momento em que o pagamento é confirmado, e é ele que precisa acionar onboarding, tag de produto e registro de valor. Boleto emitido, Pix aguardando e compra em análise não entram nessa URL.

PURCHASE_COMPLETE não é sinônimo de compra aprovada, e tratar os dois como equivalentes é um erro que aparece bastante. Ele só dispara depois de encerrado o prazo de reembolso, sete dias após a compra. Ou seja, o comprador aprovado hoje só gera esse evento na semana que vem.

Isso torna o PURCHASE_COMPLETE inútil para onboarding, e valioso para outra coisa: é o carimbo de receita consolidada. Uma venda com PURCHASE_APPROVED mas sem PURCHASE_COMPLETE ainda pode virar reembolso. Uma venda com os dois é dinheiro que ficou.

Na prática, o mais limpo é usar os dois com funções separadas. PURCHASE_APPROVED cria o contato, aplica a tag do produto e dispara o onboarding. PURCHASE_COMPLETE marca um campo de "compra consolidada" no contato, e é esse campo que alimenta o cálculo de LTV real e os segmentos de upsell. Assim você para de ofertar upsell para quem ainda está dentro da janela de garantia, e para de contar como receita algo que pode voltar.

Para recuperação de carrinho: um webhook separado, com URL diferente, captura o evento de carrinho abandonado. Esse fluxo cria contato com tag de "carrinho abandonado" e aciona sequência de follow-up. É um pipeline paralelo, não o mesmo de clientes confirmados.

Para cancelamentos e reembolsos: um terceiro webhook trata PURCHASE_CANCELED, PURCHASE_REFUNDED e PURCHASE_CHARGEBACK. Esse fluxo remove a tag de produto ativo, atualiza o status do contato e pode acionar o time de CS. O contato não sai do CRM, mas o contexto muda.

Mapear todos esses eventos não é trabalho de uma tarde, mas é o que separa um CRM que registra vendas de um CRM que opera a receita de verdade. A diferença prática aparece quando você tenta responder perguntas como: quantos alunos ativos tenho hoje? Qual é o LTV real por produto? Qual é o meu churn mensal em assinaturas? Sem esses eventos tratados, você está respondendo essas perguntas no chute.

Eventos de uso: o que acontece depois da compra

Até aqui a stack toda gira em torno de eventos de transação. Comprou, cancelou, reembolsou. Só que o CRM que sabe apenas quem comprou continua cego para a coisa mais importante de qualquer operação de infoproduto, que é saber quem está usando.

Para produtos hospedados no Hotmart Club, a plataforma dispara eventos de consumo além dos de venda. O primeiro acesso à área de membros, o progresso de conclusão de módulo ou aula, a conclusão do curso, a emissão do certificado. São eventos com a mesma natureza dos outros: chegam por webhook, carregam o email do aluno e o identificador do produto, e podem alimentar o CRM pela mesma arquitetura.

A diferença é o que eles permitem fazer.

Recuperar quem comprou e sumiu. Esse é o caso de uso que paga a implementação sozinho. Comprador que não registrou primeiro acesso em cinco dias é o perfil que mais pede reembolso, porque ele não teve nenhuma experiência com o produto para justificar ter gastado o dinheiro. Com o evento de acesso chegando no CRM, você monta uma automação simples e brutal na eficácia: entrou tag de compra aprovada, não entrou tag de primeiro acesso em N dias, dispara sequência de ativação. Email, WhatsApp, os dois. Como isso roda dentro da janela de garantia, ele ataca o reembolso antes do reembolso acontecer.

Parar de tratar todo comprador igual. Quem concluiu o curso e quem nunca abriu a plataforma estão no mesmo segmento do seu CRM hoje, e recebem a mesma oferta de upsell. Com progresso registrado em campo customizado, isso se divide. Aluno que concluiu é o público natural para o produto seguinte, para programa avançado, para mentoria. Aluno travado no módulo dois precisa de conteúdo de suporte, não de oferta. A mesma campanha enviada para os dois converte no primeiro e queima o segundo.

Dar contexto real para o vendedor no WhatsApp. O DataCrazy recebe esses eventos pelo mesmo caminho da compra. O vendedor deixa de ver só "comprou o produto X" e passa a ver "comprou o produto X, está em 70% do curso". Isso é a diferença entre uma abordagem genérica e uma conversa que começa de onde a pessoa está.

Antecipar churn em recorrência. Se o produto é assinatura, queda de consumo é o indicador que aparece antes do cancelamento. Aluno que acessava toda semana e parou há três semanas é um cancelamento em formação. O evento de acesso alimenta um campo de última atividade, e a partir dele você aciona retenção enquanto ainda dá tempo. Combinado com o evento de troca de plano e com o de assinatura atrasada, você tem um sinal de risco bem antes da cobrança falhar.

Vale um alerta de arquitetura aqui, porque esse é o ponto onde a stack começa a doer.

Eventos de uso têm volume muito maior que eventos de venda. Uma compra gera um evento. Um aluno ativo gera dezenas por semana. Se você jogar cada acesso e cada aula concluída como um update no contato do CRM, você vai estourar limite de API, encher o histórico do contato com ruído e deixar a base pesada sem ganhar nada com isso.

O tratamento correto é agregar, não espelhar. O CRM não precisa saber que o aluno assistiu a aula 14 às 22h47. Ele precisa de três campos: data do primeiro acesso, data do último acesso e percentual de conclusão. Cada evento novo sobrescreve esses campos, não cria um registro adicional.

E é aqui que a escolha da camada do meio deixa de ser indiferente. Roteamento nativo funciona bem quando um evento vira uma ação. Eventos de uso pedem o contrário: receber muitos, agregar e escrever pouco.

LGPD e dados de compra: o que a automação precisa respeitar

Quando dados de compra trafegam entre Hotmart, ListBoss, ActiveCampaign e DataCrazy, você está processando dados pessoais: nome, email, valor pago, produto adquirido, comportamento de compra. A LGPD incide sobre todo esse fluxo, e sobre cada peça dele.

A base legal precisa estar definida antes de configurar qualquer automação. Legítimo interesse funciona para comunicações de relacionamento com clientes existentes. Consentimento explícito é necessário para usos que o comprador não esperaria ao fechar uma compra. A finalidade de cada dado precisa estar declarada na política de privacidade. E o direito de acesso e remoção do titular tem que estar operacional, o que significa que excluir um contato do ActiveCampaign não pode deixar rastro em logs não gerenciados nem no histórico de conversas do WhatsApp.

A transmissão via webhook precisa acontecer por HTTPS. ListBoss, ActiveCampaign, DataCrazy e WeSales já operam em HTTPS por padrão. O ponto de atenção é o n8n auto-hospedado, que em instalação improvisada pode ficar exposto sem certificado. Se você escolheu o caminho do n8n, esse é o item que não pode passar batido.

Vale acrescentar que quanto mais peças na stack, mais superfícies para mapear no seu inventário de tratamento de dados. Consolidar na WeSales reduz esse trabalho. Não é o argumento principal para escolher uma arquitetura, mas é um argumento real.

Perguntas frequentes

Preciso do n8n para integrar Hotmart com ActiveCampaign?

Não. O ListBoss faz essa ponte de forma nativa, com interface visual, sem servidor para manter. O n8n vira necessário quando a lógica passa de "evento X gera ação Y": consulta a APIs externas, condicionais aninhadas, transformação não trivial de payload, ou normalização de múltiplas plataformas de checkout num formato único.

O DataCrazy precisa do n8n para receber dados da Hotmart?

Não. O DataCrazy recebe webhook nativo da Hotmart. Você cadastra a URL dele direto no painel da Hotmart como um segundo destino, em paralelo ao ListBoss. Os dois caminhos operam de forma independente.

O que acontece se a camada do meio ficar fora do ar quando a Hotmart tentar enviar um evento?

A Hotmart tenta reenviar por um período, mas não indefinidamente. Se o destino ficar fora do ar por tempo suficiente, o evento se perde. Com ListBoss e DataCrazy esse risco é da própria plataforma, que opera em infraestrutura gerenciada. Com n8n auto-hospedado o risco é seu, e é por isso que monitoramento e log de execuções deixam de ser opcionais.

Como integrar Kiwify ou Eduzz usando a mesma arquitetura?

O conceito é idêntico: webhook da plataforma de checkout apontando para a camada de roteamento, que processa e chama a API do CRM. O que muda é o formato do payload de cada plataforma. Se você opera com várias ao mesmo tempo e quer normalizar tudo num formato único antes de entrar no CRM, esse é justamente um dos cenários em que o n8n compensa o trabalho extra.

Como calcular LTV real de clientes no ActiveCampaign com dados da Hotmart?

Cada venda aprovada precisa registrar o valor pago em campo numérico customizado no contato. Com múltiplas compras do mesmo contato, você usa um campo de valor acumulado que é incrementado a cada nova compra. O ActiveCampaign permite filtrar e segmentar por ranges de valor nesse campo, o que viabiliza relatório de LTV por faixa, por produto de entrada e por período, direto na plataforma, sem exportação.