Welcome!
What did you do?
Atualmente, possuo um fluxo no n8n que, ao cadastrar um contato no Chatwoot, remove o nono dígito do número — exceto para DDDs entre 11 e 29, onde ele é mantido (sabemos que nesses casos o 9 é obrigatório e sua remoção alteraria o número real).
O problema é que, por exemplo, meu DDD é 62 e muitos contatos criaram o WhatsApp com o nono dígito. Dessa forma, quando um contato inicia uma conversa, o Chatwoot cria um novo chat sem identifier, como se fosse um contato diferente, já que o número originalmente salvo no sistema está sem o 9.
Não sei se isso e um problema na forma que que a Evolution faz a busca do identifier para associação do chat na mesma conversa.
Abaixo está o script que estou usando para remover o nono dígito:
const phone_number = $json.body.phone_number; // Ex: +5532999814558
let cleaned_number = phone_number.replace(/[+\s-]/g, ""); // Remove +, espaços e traços
// Pega o DDD (3º e 4º dígitos do número completo com DDI Brasil = 55)
const ddd = parseInt(cleaned_number.slice(2, 4));
// Número local (depois do DDD)
let local_number = cleaned_number.slice(4);
// Se o DDD for fora da faixa 11–29 e o número local tiver 9 dígitos e começar com '9', remover o primeiro dígito
if ((ddd < 11 || ddd > 29) && local_number.length === 9 && local_number.startsWith('9')) {
local_number = local_number.slice(1);
}
// Monta número final com DDI + DDD + número local corrigido
const final_number = cleaned_number.slice(0, 4) + local_number;
// Adiciona o sufixo @s.whatsapp.net
const remoteJid = ${final_number}@s.whatsapp.net;
// Retorna o número ajustado e o remoteJid
return {
cleaned_phone_number: final_number,
remoteJid: remoteJid
};
What did you expect?
A Evolution deve buscar associar o chat ao identifier de forma que, independentemente de o número ter ou não o nono dígito e sendo do mesmo DDD, o chat seja vinculado corretamente ao ID da conversa no Chatwoot.
What did you observe instead of what you expected?
A Evolution associa a conversa com base no identifier. Com isso, se o identifier estiver com um 9 a mais no início do número, ele não consegue vincular à mesma conversa e acaba abrindo um novo chat no Chatwoot. Seria interessante implementar uma validação que, ao detectar o mesmo DDI e DDD, trate números com ou sem o nono dígito como sendo do mesmo contato, para que a conversa seja corretamente vinculada.
Screenshots/Videos
No response
Which version of the API are you using?
Versão: 2.2.3
What is your environment?
Linux
Other environment specifications
No response
If applicable, paste the log output
No response
Additional Notes
No response
Welcome!
What did you do?
Atualmente, possuo um fluxo no n8n que, ao cadastrar um contato no Chatwoot, remove o nono dígito do número — exceto para DDDs entre 11 e 29, onde ele é mantido (sabemos que nesses casos o 9 é obrigatório e sua remoção alteraria o número real).
O problema é que, por exemplo, meu DDD é 62 e muitos contatos criaram o WhatsApp com o nono dígito. Dessa forma, quando um contato inicia uma conversa, o Chatwoot cria um novo chat sem identifier, como se fosse um contato diferente, já que o número originalmente salvo no sistema está sem o 9.
Não sei se isso e um problema na forma que que a Evolution faz a busca do identifier para associação do chat na mesma conversa.
Abaixo está o script que estou usando para remover o nono dígito:
What did you expect?
A Evolution deve buscar associar o chat ao identifier de forma que, independentemente de o número ter ou não o nono dígito e sendo do mesmo DDD, o chat seja vinculado corretamente ao ID da conversa no Chatwoot.
What did you observe instead of what you expected?
A Evolution associa a conversa com base no identifier. Com isso, se o identifier estiver com um 9 a mais no início do número, ele não consegue vincular à mesma conversa e acaba abrindo um novo chat no Chatwoot. Seria interessante implementar uma validação que, ao detectar o mesmo DDI e DDD, trate números com ou sem o nono dígito como sendo do mesmo contato, para que a conversa seja corretamente vinculada.
Screenshots/Videos
No response
Which version of the API are you using?
Versão: 2.2.3
What is your environment?
Linux
Other environment specifications
No response
If applicable, paste the log output
No response
Additional Notes
No response