Recorre-se ao n8n quando o CRM precisa conversar com algo que ele desconhece: um banco do estoque, um serviço interno, uma API de terceiros. E a primeira hora vai embora numa pergunta que os tutoriais evitam: não existe um nó «Bitrix24» pronto para arrastar até a tela. A conexão funciona mesmo assim, só que montada com blocos genéricos — e depois ela quebra sempre nos mesmos pontos. Abaixo, o formato que se sustenta para ligar Bitrix24 (Alaio) e n8n nas duas direções.

Existe um nó do Bitrix24 no n8n?

Oficial, não. A própria página do Bitrix24 no n8n aponta para o nó HTTP Request com autenticação genérica, o que é a resposta honesta: a API REST você chama por conta própria. Há pacotes da comunidade, e alguns cobrem bem entidades de CRM, tarefas e telefonia, mas são mantidos por terceiros, ficam atrás das mudanças da API e, em instâncias gerenciadas, instalá-los é uma decisão de política, não um clique. Para um cenário de três ou quatro métodos, o nó HTTP Request dá menos trabalho do que auditar código alheio: a API é JSON simples sobre HTTPS e um nó atende qualquer método.

Como o n8n grava dados no Bitrix24?

Por um webhook de entrada. No portal ele é criado na área para desenvolvedores: você marca as permissões necessárias e recebe um endereço no formato https://<portal>/rest/<id-do-usuario>/<token>/<metodo>.json. A autorização está no próprio endereço, então o nó HTTP Request não precisa de nada além desse link e de cuidado ao manuseá-lo. Nome do método e parâmetros vão exatamente como a documentação descreve: crm.item.add, crm.item.update, tasks.task.add.

Duas propriedades desse endereço decidem quase tudo o que vem depois. O webhook trabalha com as permissões do funcionário que o criou: um cenário sem acesso a um funil falha por permissão com um token perfeitamente válido — por isso crie webhooks numa conta de serviço, e não na de quem estava no computador naquele dia. E o token não se renova sozinho: vive até alguém apagá-lo ou desativar esse funcionário, daí a comodidade e daí o preço de um vazamento. A mecânica das duas direções está no guia de webhooks.

Como disparar um cenário do n8n a partir do Bitrix24?

São dois caminhos, e eles se comportam de forma diferente. O webhook de saída do portal assina eventos — negócio alterado, lead criado — e bate no endereço do seu nó Webhook. Ele dispara a cada evento compatível, tenha a alteração vindo de uma pessoa, de uma importação ou de outra integração. O conteúdo chega como dados de formulário e não como JSON, e é por isso que na primeira execução o nó mostra campos avulsos em vez de um corpo.

O segundo caminho chama o n8n de dentro do próprio processo. A regra Requisição HTTP GET/POST atinge o endereço do nó Webhook exatamente no ponto que você escolher e envia apenas os dados que você decidir enviar. Construir JSON a partir de campos monta o corpo com valores do processo sem escapar aspas na mão, e Extrair valor de JSON por caminho traz a resposta do n8n de volta para o processo — o tratamento de respostas está detalhado no artigo sobre JSON nos processos de negócio. Onde a entrega não pode se perder — um pedido que entra em produção, um documento que vai para assinatura — use o Webhook tolerante a falhas: ele repete no próprio ritmo e informa quantas tentativas foram necessárias, em vez de silenciar após a primeira falha.

Qual metade do cenário é melhor deixar no portal?

A metade que nunca sai dele. Mudar de etapa, preencher um campo, criar uma tarefa, ramificar por uma condição: levar isso para um cenário externo compra uma ida e volta pela rede, um segundo lugar para depurar e uma cota para vigiar — e mais nada. A divisão sensata é simples: o n8n cuida dos sistemas de fora, o portal cuida dos próprios registros, e entre eles uma chamada. O custo dessa decisão está destrinchado na comparação entre conectores e automação dentro do portal; a parte interna é a configuração de regras de automação de sempre.

Por que o cenário fica mudo?

Comece pelo lado do n8n: o nó Webhook tem dois endereços, um de teste e um de produção, e o de produção só responde com o cenário ativo — uma conexão construída e verificada em modo de teste emudece justamente quando ninguém mais está olhando. Depois o lado do portal: um webhook de saída preso ao evento errado, ou a um tipo de entidade que a regra nunca toca, não gera requisição alguma; lista de execuções vazia no n8n é problema de assinatura, não de rede.

Se as requisições chegam e voltam com erro, leia o texto em vez de tentar de novo: falta de permissão do webhook, código de campo errado e limite estourado se parecem todos com «não funciona», mas se resolvem de maneiras diferentes. O limite merece espaço próprio na cabeça — o portal aceita algumas chamadas por segundo, e um laço sobre algumas centenas de registros sem pausas esbarra nele sozinho. E quando quem não partiu foi a regra pela qual tudo deveria começar, o roteiro está em por que as regras de automação não funcionam.

Para onde ir depois

Decomponha seu cenário em duas listas: passos que tocam sistemas externos e passos que tocam apenas registros do portal. A segunda lista se muda para dentro — normalmente sobra um webhook em cada direção, e isso se mantém vivo com muito menos esforço. Os blocos da parte interna estão no catálogo de regras, e se faltar o que você precisa, descreva a tarefa: a Roboteka cria as regras que faltam de graça e as publica na biblioteca comum.