Ligar o WhatsApp ao CRM Bitrix24 num número Coexistence

Como comunica o n8n com o Bitrix24?

Através de um webhook de entrada, que no Bitrix24 não é um recetor mas uma credencial. Cria-se nos recursos para programadores do Bitrix24, escolhem-se os âmbitos que pode usar e obtém-se um URL com o endereço do portal, o id do utilizador que o criou e um código secreto. Ao acrescentar o nome de um método a esse URL, chama-se a API REST como esse utilizador, com as permissões desse utilizador.

Assim, no n8n cada passo do Bitrix24 é um nó HTTP Request que faz um pedido POST a esse URL mais um método, como crm.lead.add.json. Não há fluxo OAuth para concluir nem app para publicar. Dê ao webhook apenas o âmbito do CRM e crie-o a partir de um utilizador cujas permissões abranjam os leads e contactos que o workflow deve ver, já que o Bitrix24 verifica o acesso como esse utilizador.

Que métodos do Bitrix24 chama o workflow?

Três, por ordem, depois de o nó Webhook do n8n receber a mensagem da Meta.

O crm.duplicate.findbycomm com o tipo PHONE e o número do remetente devolve os ids de quaisquer leads, contactos e empresas que o tenham. É a pesquisa certa porque procura nos três ao mesmo tempo e foi concebida para correspondência por meios de comunicação, e não por um campo de texto.

Quando não devolve nada, o crm.lead.add cria um lead com o nome do perfil do WhatsApp como título e o número no campo de telefone. Depois, o crm.timeline.comment.add escreve o texto da mensagem como comentário no registo, com ENTITY_TYPE, ENTITY_ID e COMMENT. O comentário aparece na cronologia do registo ao lado das chamadas e dos emails, onde um comercial já costuma olhar.

POST https://yourcompany.bitrix24.com/rest/1/<secret>/crm.duplicate.findbycomm.json
{ "type": "PHONE", "values": ["14155550188"] }

POST .../crm.lead.add.json
{ "fields": { "TITLE": "WhatsApp: Maria", "PHONE": [{ "VALUE": "14155550188", "VALUE_TYPE": "MOBILE" }] } }

POST .../crm.timeline.comment.add.json
{ "fields": { "ENTITY_TYPE": "lead", "ENTITY_ID": 4211, "COMMENT": "do you have anything friday?" } }

Como condiciona o limite de pedidos o workflow?

O Bitrix24 mede os pedidos REST com um balde com fuga. Cada pedido soma ao contador, o contador desce a um ritmo fixo por segundo e, quando ultrapassa um limite, o pedido seguinte recebe um 503 com QUERY_LIMIT_EXCEEDED. Nos planos Enterprise o contador desce 5 por segundo, com limite de 250; em todos os outros planos desce 2, com limite de 50.

Cada mensagem recebida custa dois ou três pedidos, pelo que um fluxo constante nunca se aproxima do limite. Um pico já se aproxima: cinquenta clientes a responder ao mesmo template no espaço de um minuto são até 150 pedidos. Configure os nós HTTP Request para voltar a tentar em caso de falha, com uma espera curta, e execute as execuções do workflow uma de cada vez, para que o pico seja absorvido pelo Bitrix24 em vez de ser rejeitado.

As respostas escritas no telemóvel chegam ao Bitrix24?

Podem chegar. Num número Coexistence, a app WhatsApp Business continua a funcionar e, quando alguém responde a partir dela, a Meta envia um eco da mensagem enviada para o mesmo destino de webhook, no campo smb_message_echoes.

Um segundo ramo do workflow trata esses ecos do mesmo modo que as mensagens recebidas, com o comentário marcado como enviado. O registo passa então a mostrar a conversa completa, com as falas do cliente e as respostas da loja por ordem.

As respostas que o próprio workflow envia através da Cloud API já estão nas mãos do workflow quando saem, por isso registe-as nesse momento em vez de esperar que um webhook volte.

Erros comuns

• Colar o URL do webhook de entrada em código do lado do cliente ou num documento partilhado. O segredo que contém concede todos os âmbitos atribuídos ao webhook.
• Criar o webhook a partir de um utilizador que não vê todos os leads. As pesquisas falham registos e o workflow cria duplicados.
• Enviar um pico de pedidos sem repetições. O Bitrix24 responde 503 QUERY_LIMIT_EXCEEDED e essas mensagens nunca chegam à cronologia.

Perguntas frequentes

Continue a ler