Pular para o conteúdo

n8n

O n8n é uma ferramenta de automação: você monta um fluxo ligando caixinhas (chamadas de nós) e ele faz o trabalho sozinho. Com a API do CRM, um fluxo do n8n pode mandar leads e vendas para o CRM e também ser avisado quando algo acontece nele.

O jeito mais fácil é o nó do Datta CRM (pacote n8n-nodes-datta-crm). Ele traz três peças:

  • a credencial Datta CRM API, onde fica a sua chave;
  • o nó Datta CRM, que cria e altera leads, vendas, listas, formulários e rascunhos de e-mail, e envia a mídia dos anúncios;
  • o nó Datta CRM Trigger, que começa um fluxo quando algo acontece no CRM.

Os nomes dentro do n8n aparecem em inglês, e este artigo os escreve do mesmo jeito.

  • Tenha uma conta no n8n.
  • Crie uma chave de API no CRM, com acesso de Leitura e escrita: o gatilho do nó e os envios de leads e vendas gravam no CRM. Veja o passo a passo em Chaves de API.
  • Prefira uma chave com validade (a de 90 dias, por exemplo). Uma chave sem vencimento só vale a pena quando você precisa de uma conexão direta e permanente. Veja mais em Validade.

Primeiro, procure o nó no painel do n8n:

  1. Abra um fluxo. Em um fluxo novo ou existente, clique em + para adicionar um nó.

  2. Procure por Datta CRM. Digite Datta CRM na busca.

  3. Escolha o nó. Se o Datta CRM aparecer, clique nele e siga as instruções na tela para instalar. Depois, pule para Criar a credencial.

Se ele não aparecer e o seu n8n é instalado em um servidor próprio, instale pelo nome do pacote. Para isso, você precisa ser dono ou administrador do n8n:

  1. Abra as configurações. Clique em Settings e depois em Community Nodes.

  2. Comece a instalação. Clique em Install.

  3. Digite o nome do pacote. No campo do pacote (npm Package Name), digite n8n-nodes-datta-crm.

  4. Confirme e instale. Marque a caixa que confirma que você entende os riscos de instalar um pacote da comunidade e clique em Install.

A credencial guarda a sua chave dentro do n8n. Você cria uma vez e usa em todos os nós do Datta CRM.

  1. Adicione um nó Datta CRM. Clique em +, procure por Datta CRM e escolha o nó Datta CRM.

  2. Crie a credencial. Em Credential to connect with, escolha Create new credential.

  3. Cole a chave. Em API Key, cole a sua chave (ela começa com crm_live_).

  4. Deixe o endereço como está. O campo Base URL já vem com https://dattacrm.com.br. Só troque se alguém da Datta pedir.

  5. Salve. Clique em Save. O n8n testa a chave na hora e mostra se a conexão deu certo.

Se aparecer um erro, confira se a chave foi colada inteira e se ela não venceu nem foi revogada. Veja Erros comuns.

Quando você trocar a chave, edite esta credencial e cole a nova. Todos os nós que usam a credencial passam a usar a chave nova.

  1. Escolha o recurso. No nó Datta CRM, em Resource, escolha Lead.

  2. Escolha a operação. Em Operation, escolha Create or Update.

  3. Informe o e-mail ou o telefone. Preencha Email, Phone ou os dois. Para usar o que chegou do nó anterior, arraste o campo da esquerda para cá.

  4. Acrescente o que mais quiser. Em Additional Fields, clique em Add Field para incluir nome, tags, listas, origem, UTMs e outros. A partir da versão 0.5.0 do nó, há também os campos de rastreio de clique e de página (Facebook Click ID (fbclid), Google Click ID (gclid), TikTok Click ID (ttclid), Page URL, Referrer e outros). Tags e listas aparecem em listas carregadas da sua conta. Para criar um lead, escolha pelo menos uma lista: a chave não tem lista, então é aqui que você decide para onde o lead vai. A etapa não é mais um campo do lead: ela é do negócio em cada lista (veja o aviso abaixo).

  5. Execute o nó. Clique em Execute step. A saída mostra o lead e se ele foi criado (created) ou já existia (matched).

Uma tag automática enviada aqui é ignorada: o CRM a põe e tira pela regra dela.

Se o lead já existe, o CRM só preenche o que estava vazio e junta as tags e listas. Para trocar um dado que já está preenchido, use a operação Update. Para mexer só nas tags ou nas listas, use Add Tags, Remove Tags, Add to Lists ou Remove From Lists.

Toda lista fica dentro de uma pasta, e a pasta define a origem da lista (Site, WhatsApp ou Instagram). A operação List → Create do nó manda só o nome. Isso funciona quando a origem tem uma única pasta: a lista vai para ela. Sem folderId, a origem é Site.

Se a origem não tem pasta, ou tem mais de uma, a API responde 400 folder_required. Nesse caso, crie a lista pelo HTTP Request (POST /lists) e mande o folderId da pasta. Os ids das pastas vêm de GET /folders (operação list_folders); para outra origem sem folderId, mande "origin": "whatsapp" ou "origin": "instagram". Veja a operação create_list.

Montando o fluxo de um formulário novo, pode aparecer uma pergunta que ainda não tem campo personalizado no CRM. Dá para criar o campo pelo próprio n8n, sem voltar ao CRM. São dois jeitos:

  • Custom Field → Create. Um nó só para criar o campo. Preencha Name (o nome que aparece na tela) e escolha o Type. A Key é opcional: sem ela, sai do nome (Cargo do lead vira cargo_do_lead). Para Select e Multi Select, escreva as opções em Options, separadas por vírgula. Se o campo já existe com a mesma chave e o mesmo tipo, o nó devolve o campo como está, com result: matched, e não muda nada. Com a mesma chave e outro tipo, o CRM responde 409 conflict.
  • Create Missing Custom Fields, no Lead → Create or Update. Em Additional Fields, ligue essa opção. Antes de mandar o lead, o nó cria como texto as chaves de Custom Fields que ainda não existem na conta, usando a própria chave como nome. Depois, troque o nome ou o tipo na aba Campos do CRM, se quiser.

Nos dois jeitos, a chave aceita só letras sem acento, números e _, até 40 caracteres, e é gravada em minúsculas. Chave ou nome de um campo do CRM do CRM não pode ser usado: name, email, phone, as UTMs (utm_source e as outras) e o rastreio (fbclid, gclid, page_url e os outros). Nesse caso o CRM responde 400 e o item falha sem mandar o lead; mande esse dado no campo próprio do lead (Email, Phone ou, em Additional Fields, as UTMs e os campos de rastreio). Campo personalizado que já existia com uma dessas chaves continua valendo. Para escrever uma chave que ainda não está na lista de Custom Fields, passe o campo Field Name or ID para Expression e digite a chave. O campo novo já aparece na lista na próxima vez que você abri-la.

Essas opções vêm na versão 0.6.0 do nó. A chave precisa ser de Leitura e escrita. Pela API, use a operação create_custom_field.

O campo criado pelo nó vai para o grupo padrão, Geral. Para pô-lo em outro grupo de campos, use Editar na aba Campos do CRM, ou crie o campo pelo HTTP Request (POST /custom-fields) com "group" igual ao nome ou ao id de um grupo que já existe.

  1. Escolha o recurso e a operação. No nó Datta CRM, em Resource, escolha Sale. Em Operation, escolha Create or Update.

  2. Preencha os três campos obrigatórios. Transaction ID é o código único da venda (o número do pedido, por exemplo). Status é a situação. Value é o valor.

  3. Informe quem comprou. Em Additional Fields, clique em Add Field e escolha Buyer. Depois clique em Add Buyer Detail e preencha Email ou Phone. Assim a venda é ligada ao lead, que é criado se ainda não existir.

  4. Execute o nó. Clique em Execute step. A saída mostra a venda e se ela foi criada ou atualizada.

Mandar o mesmo Transaction ID de novo atualiza a venda em vez de criar outra. Por isso, quando o pagamento cair, basta mandar o mesmo código com o novo Status. Isso vale enquanto o Gateway (em Additional Fields) for o mesmo; se você não preencher, o padrão é api.

Para o relatório Desempenho mostrar o investimento ao lado dos cadastros e das vendas, o fluxo precisa mandar ao CRM as métricas dos anúncios (gasto, impressões, cliques e conversões da plataforma, um registro por anúncio e por dia). O recurso Ad Metric do nó faz isso. Ele vem na versão 0.7.0 do nó, e a chave precisa ser de Leitura e escrita. Pela API, use a operação upsert_ad_metrics.

  1. Escolha o recurso e a operação. No nó Datta CRM, em Resource, escolha Ad Metric. Em Operation, escolha Send.

  2. Escolha a plataforma. Em Platform, escolha Meta, Google, TikTok ou LinkedIn. Um nó manda uma plataforma por vez.

  3. Diga de onde vêm os registros. Em Records, escolha Use Input Items para mandar cada item que chega ao nó como um registro, ou JSON para escrever a lista no próprio nó.

  4. Confira o formato de cada registro. Todo registro precisa de date (no formato AAAA-MM-DD) e adId. O resto é opcional: campaignName, adsetName, adName, spend, impressions, clicks e os demais campos que a plataforma informa. Os nomes ficam em inglês e em camelCase, como no resto da API.

  5. Execute o nó. O nó manda os registros em lotes de até 500 (o tamanho do lote fica em Batch Size). A saída mostra quantos registros foram gravados.

Bom saber:

  • Reenviar é seguro. O registro é identificado pela plataforma, pelo dia e pelo adId. Mandar de novo atualiza o que já existe e não duplica. Por isso vale reenviar a janela de dias que a plataforma ainda corrige (7 dias na Meta e no TikTok, 30 no Google). O que não vem no registro fica como estava; só o extra, quando enviado, substitui o anterior por inteiro.
  • Nomes iguais aos da UTM. O Desempenho liga cadastros e vendas ao anúncio pelo nome da campanha, do conjunto e do anúncio. Mande campaignName, adsetName e adName exatamente como estão na plataforma, e use esses mesmos nomes nas UTMs dos links. Veja como a ligação funciona.
  • Moeda. A mídia é gravada na moeda que a plataforma informa, sem conversão. Se mandar currency, ela tem que ser a mesma moeda da conta no CRM; senão o lote inteiro é recusado.
  • Um erro recusa o lote. Se um registro for inválido (data fora do formato, por exemplo), nada daquele lote é gravado e o erro diz qual registro falhou.
  • Não conta no plano. A mídia não entra no limite de leads nem de vendas do plano.

Além da mídia por dia, o fluxo pode mandar a fotografia da estrutura: o estado atual de cada campanha, conjunto e anúncio, com o status, a veiculação (ativa, em análise, reprovada…) e os orçamentos. Com ela, o CRM sabe o que está no ar agora, e não só o que gastou ontem. O nó do Datta CRM ainda não tem um recurso para isso: use um nó HTTP Request com POST https://dattacrm.com.br/api/v1/ad-entities, configurado como em Registrar uma venda (mesma credencial, Leitura e escrita). Os campos estão na operação upsert_ad_entities.

O corpo traz a plataforma e de 1 a 500 registros, um por entidade:

{
"platform": "meta",
"records": [
{
"level": "campaign",
"entityId": "120210000000000001",
"name": "PND | Captação",
"status": "ACTIVE",
"effectiveStatus": "ACTIVE",
"dailyBudget": 150,
"collectedAt": "2026-11-04T13:00:00Z"
},
{
"level": "ad",
"entityId": "120210000000000003",
"name": "Vídeo 1",
"campaignName": "PND | Captação",
"adsetName": "Público quente",
"status": "ACTIVE",
"effectiveStatus": "ADSET_PAUSED",
"collectedAt": "2026-11-04T13:00:00Z"
}
]
}

Bom saber:

  • level é campaign, adset ou ad. Com a plataforma e o entityId, identifica o registro: mandar de novo atualiza, não duplica. O que não vem fica como estava.
  • collectedAt é obrigatório: a hora em que a plataforma foi lida, em ISO com fuso. Hora no futuro (mais de 10 minutos à frente) recusa o lote. Um reenvio atrasado, com hora mais antiga que a já gravada, não desfaz o estado mais novo.
  • Nomes iguais aos da mídia. Mande name, campaignName e adsetName como na plataforma: é pelo nome que o CRM liga a estrutura às linhas do Desempenho.
  • Duas vezes por dia. O fluxo da Datta lê a estrutura à 0h e às 12h, e a fotografia de cada plataforma vale por 14 horas. Se o fluxo de uma plataforma parar, o CRM volta a deduzir o status dela pela mídia de ontem e de hoje, sem a veiculação. Entidade que fica 30 dias sem ser enviada sai sozinha.
  • Orçamentos ficam na moeda da conta de anúncios, sem conversão, e não contam no plano.

A mídia que o CRM tem na conta, coletada por ele (pela conexão em Contas de anúncios) ou enviada pela API, pode ser lida de volta. Qualquer chave serve, inclusive a Somente leitura.

  • Métricas por anúncio e dia: list_ad_metrics, GET /api/v1/ad-metrics. Exige since e until (AAAA-MM-DD, até 93 dias entre os dois). Filtra por platform e por campaignId.
  • Estrutura de mídia: list_ad_entities, GET /api/v1/ad-entities. Filtra por platform e level (campanha, conjunto ou anúncio).

As duas devolvem de 1 a 500 registros por página (100 por padrão). Quando houver mais, a resposta traz nextCursor: mande-o no parâmetro cursor para a página seguinte. Quando vier nulo, acabou.

Nos planos sem painel de anúncios (Free e Plus) a leitura é recusada com plan_required (403). Os dados ficam guardados e voltam a ser lidos quando a conta assina o Pro, o Max ou o Agência. Para ser avisado quando chega mídia nova, use o evento Mídia sincronizada dos webhooks de saída.

O nó Datta CRM Trigger começa o fluxo quando algo acontece no CRM: um lead novo, uma venda paga, uma mudança de etapa.

  1. Adicione o gatilho. Em um fluxo novo, clique em Add first step (ou em +), procure por Datta CRM e escolha Datta CRM Trigger.

  2. Escolha a credencial. Em Credential to connect with, escolha a credencial Datta CRM API que você criou (ou Create new credential, como em Criar a credencial).

  3. Escolha os eventos. Em Event Names or IDs, marque um ou mais acontecimentos. A lista vem da sua conta.

  4. Filtre, se quiser. Em Filters, clique em Add Filter e limite os avisos por lista, etapa, tag, formulário, produto, origem ou canal. Cada filtro vale só para os eventos que o aceitam.

  5. Deixe a proteção contra laço ligada. A opção Ignore Changes Made by This API Key já vem ligada. Veja abaixo por quê.

  6. Ative o fluxo. Clique em Publish (em versões mais antigas do n8n, Active). Nesse momento o n8n cria o aviso no CRM sozinho. Ao desativar o fluxo, o aviso é removido.

Bom saber:

  • Proteção contra laço. Com Ignore Changes Made by This API Key ligada, o fluxo não é avisado do que ele mesmo fez no CRM com essa credencial. Sem isso, um fluxo que altera o lead que o disparou seria disparado de novo, sem parar. A proteção não cobre o que uma automação do CRM fizer depois, em reação à mudança: isso continua sendo avisado.
  • HTTPS na porta 443. O CRM só avisa endereços https:// na porta padrão. O n8n Cloud já atende a isso. Um n8n em servidor próprio precisa de um domínio com https e sem número de porta no endereço; um n8n que só roda no seu computador não recebe avisos, a menos que tenha um endereço público com https (por exemplo, por um túnel). Endereços privados ou locais são recusados.
  • Assinatura. Cada aviso vem assinado (cabeçalho x-crm-signature). O nó confere a assinatura sozinho e descarta o que não veio do CRM.
  • Teste e produção. O n8n tem um endereço de teste e outro de produção para o mesmo nó. O gatilho cria um aviso no CRM para cada um, e um não atrapalha o outro. Cada um conta no limite abaixo.
  • Limite. Cada conta tem até 50 webhooks, somando os criados pela tela e pelo n8n.
  • Quando a chave deixa de valer. Se a chave for revogada ou vencer, os avisos criados com ela param. Cole a chave nova na credencial. Depois, desative o fluxo e ative de novo (Unpublish e Publish; em versões antigas, desligue e ligue Active). Assim o n8n cria o aviso de novo.
RecursoOperações
LeadCreate or Update, Get, Get Many, Update, Add Tags, Remove Tags, Add to Lists, Remove From Lists
ListCreate, Get Many
Custom FieldCreate, Get Many
SaleCreate or Update, Get, Get Many, Update
Ad MetricSend (a partir da versão 0.7.0 do nó)
FormCreate, Get, Get Many, Update, Activate, Deactivate
Email CampaignCreate Draft, Get, Get Many, Update Draft

Em Email Campaign, o nó só cria e altera rascunhos. Ele nunca envia e-mail: você revisa e agenda o rascunho no CRM, como em IA (ChatGPT).

O nó HTTP Request já vem no n8n e faz as mesmas chamadas, sem instalar nada. Use este caminho se o nó do Datta CRM não estiver disponível no seu n8n ou se você precisar de algo que ele não faz.

Se você ainda não fez uma chamada de teste, vale passar antes por Primeira chamada.

O fluxo tem dois nós: um que recebe os dados (por exemplo, o nó Webhook, que recebe o envio de um site ou de outra ferramenta) e um HTTP Request que cria o lead no CRM.

O nó HTTP Request é configurado exatamente como em A mesma chamada pelo n8n: método POST, endereço https://dattacrm.com.br/api/v1/leads, autenticação Header Auth com a sua chave. Faça os passos de 1 a 5 de lá. A única diferença é o corpo, que agora usa os dados do nó anterior.

  1. Abra o campo JSON do nó HTTP Request. Com Send Body ligado, Body Content Type em JSON e Specify Body em Using JSON, clique no campo JSON.

  2. Passe o campo para o modo Expression. Passe o mouse sobre o campo JSON e clique em Expression. Assim o n8n entende o que está entre {{ e }} como uma fórmula.

  3. Cole o corpo com as fórmulas. Troque os nomes depois de $json.body. pelos nomes que o seu nó Webhook recebe:

    {{ {
    "name": $json.body.name,
    "email": $json.body.email,
    "phone": $json.body.phone,
    "listId": "<id da lista>",
    "tags": ["n8n"]
    } }}
  4. Execute o fluxo. Mande um envio de teste para o nó Webhook e clique em Execute workflow. A saída do HTTP Request mostra o lead, com result igual a created ou matched.

Como ler esse corpo:

  • A fórmula inteira fica dentro de um par de {{ }}. Dentro dela, $json.body.email é “o e-mail que chegou no nó anterior”. Os textos fixos, como "n8n", ficam entre aspas.
  • Escrito assim, o n8n monta o JSON certo mesmo que o nome da pessoa tenha aspas ou acentos.
  • No nó Webhook, os dados enviados chegam dentro de body. Se o nó anterior for outro (uma planilha, um formulário do n8n), use o nome do campo dele, como $json["E-mail"].
  • A lista de destino vai no envio: "listId": "<id da lista>" (ou listIds). Criar um lead exige uma lista, porque a chave não tem lista: sem listId nem listIds, a API responde 400 list_required. O campo source é ignorado: a origem do lead é a da lista de destino.

Se o fluxo manda o lead depois de captado (uma fila, um reenvio), acrescente "occurredAt" com a hora da captura, em ISO com fuso, e "eventId" com o identificador do envio na ferramenta de origem. Assim a jornada do lead fica com a hora certa, e repetir a mesma execução não registra a entrada duas vezes. Veja Mandar de novo e ver o matched.

Se o envio traz a origem do clique, mande também "utm" e "tracking" (com fbclid, gclid, ttclid, ctwaClid, sourceId, pageUrl e referrer). Veja os campos em UTMs e rastreio de clique.

Se o lead já existe no CRM, o result volta como matched e a API só preenche o que estava vazio. Veja os detalhes em Mandar de novo e ver o matched. Todos os campos aceitos estão na operação upsert_lead.

Use o mesmo desenho: um nó que recebe os dados da venda e um HTTP Request que a registra com POST /sales.

  1. Adicione outro nó HTTP Request. Clique em + depois do nó que recebe os dados da venda e escolha HTTP Request.

  2. Configure o método e o endereço. Em Method, escolha POST. Em URL, cole:

    https://dattacrm.com.br/api/v1/sales
  3. Escolha a credencial da chave. Em Authentication, escolha Generic Credential Type e, em Generic Auth Type, Header Auth. Selecione a credencial que você já criou (Name Authorization, Value Bearer crm_live_SUA_CHAVE_AQUI).

  4. Ligue o envio do corpo. Ligue Send Body. Em Body Content Type, escolha JSON. Em Specify Body, escolha Using JSON.

  5. Cole o corpo no modo Expression. Passe o campo JSON para Expression e cole, trocando os nomes depois de $json.body.:

    {{ {
    "transactionId": $json.body.pedido,
    "status": "paid",
    "value": $json.body.valor,
    "productName": $json.body.produto,
    "buyer": {
    "name": $json.body.nome,
    "email": $json.body.email,
    "phone": $json.body.telefone
    }
    } }}
  6. Execute o nó. Clique em Execute step. A saída mostra a venda, o result e o leadId.

O que cada campo quer dizer:

  • transactionId: o número único da venda na sua origem (o código do pedido, por exemplo). É obrigatório.
  • status: a situação. paid é paga. Também existem pending, refunded, chargeback, canceled e abandoned. É obrigatório.
  • value: o valor, como número (por exemplo, 197.5), sem aspas e sem “R$”. É obrigatório. Se o valor chegar como texto do nó anterior, use Number($json.body.valor) na fórmula; texto no lugar de número faz a API responder validation_error.
  • productName: o nome do produto.
  • buyer: quem comprou. Com e-mail ou telefone, a venda é ligada ao lead dele, e o lead é criado se ainda não existir.
  • adId: o identificador do anúncio que gerou a venda, se você tiver.

A resposta traz result: "created" quando a venda é nova e result: "updated" quando ela já existia. Mandar o mesmo transactionId de novo atualiza a venda em vez de criar outra. Por isso, quando o pagamento cair, o fluxo pode mandar o mesmo transactionId com status igual a paid e o value: a venda muda de situação. Os campos que você não mandar ficam como estavam.

Mudar o status dispara os mesmos eventos e automações de uma venda registrada pela tela (reenviar o mesmo status não dispara nada de novo). Só a venda paga conta no limite de vendas do plano. Veja todos os campos na operação record_sale.

Cada envio vira um evento registrado da venda. Se chegar um status de precedência menor que o atual no mesmo instante (a ordem é chargeback, refunded, canceled, paid, pending, abandoned), o evento fica registrado, mas a venda não muda (o status atual continua o mesmo). Para corrigir uma venda de propósito, use PATCH /sales/{id} com o status: ele vale sempre e aparece no histórico como evento outro. Veja a operação update_sale.

Aqui o caminho é o inverso: o CRM avisa o n8n quando algo acontece (um lead novo, uma venda paga, uma mudança de etapa). Isso é um gatilho, também chamado de webhook de saída.

São duas partes: um nó Webhook no n8n, que recebe o aviso, e um pedido ao CRM para avisar esse endereço.

O CRM só envia avisos para endereços que comecem com https://, usem a porta 443 (a padrão, que não aparece no endereço) e não tenham ?, # nem usuário e senha. O n8n Cloud já atende a isso. Se você instala o n8n em um servidor próprio, ele precisa ter um domínio com https e o endereço não pode ter número de porta, como :5678.

  1. Adicione o nó Webhook. Em um fluxo novo, clique em Add first step (ou em +), procure por Webhook e escolha o nó.

  2. Escolha o método. Em HTTP Method, escolha POST.

  3. Ative o fluxo. Clique em Publish (em versões mais antigas do n8n, o botão se chama Active) para que a URL de produção passe a funcionar.

  4. Copie a URL de produção. No nó Webhook, abra a aba Production URL e copie o endereço. Ele é parecido com https://seu-n8n.exemplo.com/webhook/abc123.

Isso se faz uma vez só. Use um fluxo separado com um nó Manual Trigger e um HTTP Request, configurado como nos exemplos acima (Authorization com a sua chave) e com estas diferenças:

  1. Configure o método e o endereço. Em Method, escolha POST. Em URL, cole:

    https://dattacrm.com.br/api/v1/webhooks
  2. Escolha a credencial da chave. Em Authentication, escolha Generic Credential Type, Header Auth e selecione a sua credencial.

  3. Ligue o envio do corpo. Ligue Send Body, escolha JSON em Body Content Type e Using JSON em Specify Body.

  4. Cole o corpo. No campo JSON, cole e troque o targetUrl pela Production URL que você copiou:

    {
    "name": "n8n - leads novos",
    "targetUrl": "https://seu-n8n.exemplo.com/webhook/abc123",
    "events": ["lead.created"],
    "ignoreOwnChanges": true
    }
  5. Execute o nó. Clique em Execute step. A saída traz o webhook criado e o secret (o segredo).

  6. Guarde o segredo. Copie o valor de secret e guarde em um lugar seguro. Ele aparece só nesta resposta.

O que cada campo quer dizer:

  • name: um nome para você reconhecer o webhook na lista de destinos do CRM. É opcional; sem ele, o CRM usa “API · ” seguido do nome da chave.
  • targetUrl: o endereço que vai receber os avisos (a Production URL do n8n).
  • events: os acontecimentos que você quer receber, de 1 até o total de eventos listados em GET /webhooks/events. Aqui, lead.created é “lead criado”. Outros exemplos: sale.paid (venda paga), deal.stage_changed (mudou de etapa) e form.submitted (formulário enviado). A lista completa vem de GET /webhooks/events e está na operação create_webhook.
  • ignoreOwnChanges: veja abaixo. Já vem ligado por padrão; escrevê-lo no corpo só deixa a escolha visível.

Quando o fluxo com o nó Webhook estiver ativo, cada lead criado no CRM chega nele. Os dados do aviso ficam dentro de body, como $json.body.

O CRM aceita até 50 webhooks por conta (somando os criados pela tela e pela API).

Imagine um fluxo que recebe “lead criado” e, em resposta, altera esse lead no CRM com a mesma chave. Essa alteração geraria um aviso novo, que dispararia o fluxo de novo, e assim por diante, sem parar. É um laço.

Com ignoreOwnChanges em true, o webhook não avisa sobre o que a própria chave fez. Então o fluxo que escreve no CRM não se dispara sozinho.

O limite: ele só cobre mudanças feitas diretamente por essa chave. Se uma automação do CRM reagir à sua mudança e fizer outra (por exemplo, mover o lead de etapa), essa segunda mudança continua sendo avisada. Se você tem automações assim, confira que o fluxo não escreve de volta na mesma coisa que o dispara.

Cada aviso chega com o cabeçalho x-crm-signature, no formato sha256= seguido de um código. Esse código é uma assinatura calculada com o segredo que você guardou. Se o cálculo refeito no n8n der o mesmo resultado, o aviso veio mesmo do CRM.

Para quem vai montar, o cálculo é um HMAC-SHA256 do corpo exato do aviso (o texto cru, antes de virar JSON), usando o segredo, em hexadecimal. No n8n:

  • No nó Webhook, em Options, adicione Raw Body.
  • Adicione o nó Crypto.
  • Em Action, escolha Hmac.
  • No tipo, escolha SHA256.
  • Ligue Binary File e use a propriedade data, porque o corpo cru chega como arquivo (binário).
  • Informe o seu segredo.
  • Escolha a saída em hex.
  • Compare o resultado com o valor do cabeçalho x-crm-signature, sem o sha256= do início (por exemplo, com um nó If).

O mesmo cálculo também está explicado em Webhooks de saída.

Você não precisa da API para criar o aviso. Em Integrações › Webhooks › Saída, o botão Novo destino faz o mesmo, com cliques. Veja Webhooks de saída.

A diferença: os destinos criados pela tela não têm o ignoreOwnChanges. Eles avisam tudo, inclusive o que a sua própria chave faz. Se o fluxo escreve de volta no CRM, prefira criar o webhook pela API.

Os webhooks criados por uma chave dependem dela:

  • Se você revoga a chave, os webhooks que ela criou ficam desativados na hora.
  • Se a chave vence, os webhooks dela param de receber.

Para o fluxo continuar recebendo avisos, crie uma chave nova e crie o webhook de novo com ela. Veja Chaves de API.

Para parar de receber os avisos, apague o webhook. Use um nó HTTP Request com Method DELETE e, em URL, o endereço com o id do webhook no fim:

https://dattacrm.com.br/api/v1/webhooks/ID_DO_WEBHOOK

O id vem na resposta de quando você criou o webhook (campo id, dentro de webhook). Se não guardou, chame GET /webhooks com a sua chave: a lista traz o id de cada um. A resposta confirma com "deleted": true. Veja a operação delete_webhook.

Esta é a única exclusão que a API faz. Ela não apaga leads, vendas nem campanhas.

O nó Datta CRM mostra a mensagem do CRM, que explica como corrigir, e o código do erro. O nó HTTP Request mostra, na saída de erro, o code e o requestId. Veja o que cada código quer dizer em Erros comuns. Com o requestId em mãos, o suporte encontra a chamada.

Duas opções ajudam, nas configurações (Settings) de qualquer nó:

  • Retry On Fail tenta de novo sozinho. É útil quando o fluxo passa do limite de 120 chamadas por minuto e o CRM pede para esperar.
  • On Error com a opção Continue (em versões antigas, Continue On Fail) deixa o fluxo seguir quando um item falha, para você tratar o erro num passo seguinte.
Próximo passo Usar a API com IA (ChatGPT) Crie um GPT que cria rascunhos de campanha e consulta o CRM por você.