Corrigir errors.numberInvalidFormat no WebChat

Entender a validação do campo number

errors.numberInvalidFormat indica que o valor enviado no campo number não corresponde ao formato de telefone aceito pela rota. Em uma conversa de WebChat, o identificador interno da sessão ou do visitante não deve ser usado como se fosse um número telefônico.

• A rota espera DDI, DDD e número, somente com dígitos.
• Espaços, sinal de adição, parênteses, hífens ou texto podem causar rejeição quando não são aceitos pelo endpoint.
• ID de sessão, ID do ticket e identificador do visitante não substituem o telefone.
• Se o contato do WebChat não informou telefone, uma rota baseada em number não consegue deduzi-lo.

Diferenciar canal WebChat e rota telefônica

1. 1

   Confirme em qual ticket e canal a conversa foi criada.

2. 2

   Se o canal é WebChat, continue pelo ticket existente quando o contato não possui telefone cadastrado.

3. 3

   Se a integração precisa iniciar uma conversa telefônica, confirme que o contato forneceu o número e que a finalidade do uso está autorizada.

4. 4

   Não copie o identificador da sessão WebChat para o campo number.

5. 5

   Revise a documentação disponível no próprio ambiente para confirmar se o endpoint escolhido é adequado ao canal.

Corrigir a requisição

1. 1

   Confirme endpoint e método na documentação da API do seu ambiente.

2. 2

   No JSON, mantenha em number somente o telefone no padrão DDI + DDD + número e somente dígitos.

3. 3

   Remova espaços, parênteses, hífens, sinal de adição e outros caracteres antes do envio, se essa for a exigência indicada para a rota.

4. 4

   Mantenha o token no cabeçalho de autorização no formato Bearer <token>, nunca dentro do JSON ou da URL.

5. 5

   Valide os demais campos obrigatórios e execute uma única tentativa com contato de teste.

Exemplo conceitual seguro: use { "number": "<telefone_somente_digitos>" } no corpo e Authorization: Bearer <token> no cabeçalho. Substitua os marcadores somente no ambiente protegido da integração.

Validar a credencial separadamente

1. 1

   Acesse Configuração > API e identifique a credencial usada pela integração.

2. 2

   Confirme se ela está ativa e possui somente as permissões necessárias.

3. 3

   Faça primeiro uma consulta sem efeito destrutivo, quando disponível, para validar autenticação.

4. 4

   Depois teste o endpoint de envio com dados controlados.

5. 5

   Se houver suspeita de exposição, substitua o token e atualize o sistema consumidor de forma coordenada.

Validar sem gerar duplicidade

1. 1

   Use um único contato de teste autorizado.

2. 2

   Envie uma requisição e registre horário e resposta, sem o token.

3. 3

   Confirme se o erro de formato desapareceu.

4. 4

   Verifique se a mensagem entrou no ticket e no canal esperados.

5. 5

   Antes de repetir, confirme que a primeira tentativa não foi processada para evitar duplicidade.

• Endpoint compatível com a finalidade.
• number contém somente telefone autorizado e dígitos.
• Nenhum identificador de WebChat usado como telefone.
• Authorization separado do corpo.
• Resposta e resultado no ticket conferidos uma única vez.

Quando acionar o suporte

Acione o suporte se o erro continuar com endpoint correto e telefone autorizado no formato exigido, ou se a documentação do ambiente não deixar claro se aquela rota aceita contatos originados no WebChat.

• Informe data, hora, método, caminho do endpoint e estado HTTP.
• Envie o corpo com number substituído por <telefone_somente_digitos>.
• Descreva se o contato possui telefone cadastrado e se a conversa já existe no WebChat.
• Nunca envie token, cabeçalho de autorização completo, telefone, nome ou conteúdo da mensagem.