Testador Evolution 2.3.7

0Recursos

0Suportados

0Possíveis

0Com fix

-Último teste

Conexão WhatsAppUse a página Instância para criar, parear QR Code e consultar o estado da sessão.

API

Testes de envioRecursos agrupados por mídia, botões, eventos, canal/newsletter, pedidos e Z-API.

PIN

Segurança do testadorLogin por PIN no backend, sessão por cookie HttpOnly e alteração pela página Configurações.

FIX

Atualizações do pacoteHistórico robusto das correções de envio, estrutura, Manager, chat e Testador.

DOC

Documentação técnicaCausa raiz, comparação 2.3.6/2.3.7/2.4.0 e guia para próximos agentes.

Categorias cobertas

Distribuição dos recursos disponíveis no testador.

Checklist operacional

Itens importantes antes de validar envios.

1Instância conectada ou QR Code lido.

2Telefone com DDI e DDD preenchido.

3Canal/newsletter com JID real quando não estiver em modo teste.

4Retorno técnico revisado após cada envio.

Instância e conexão

Controle de ciclo da sessão WhatsApp.

Baileys

0Instâncias

0Conectadas

0Conectando

0Não conectadas

-Selecionada

No WhatsApp: Aparelhos conectados > Conectar aparelho.

Resumo do ambiente

Dados do console ativo.

Versão base2.3.7

Fix ativo-

Instância padrãoteste_evolution_237

AutenticaçãoCookie HttpOnly

Destino e recursos

Escolha o recurso, envie e acompanhe o retorno.

0 visíveis

Telefone destino

Normalizado: -

Use DDI + DDD + número. O prefixo 55 é aplicado quando possível.

Canal/newsletter JID

Use teste para simular recursos de canal em telefone comum.

Buscar

Status

Categoria

Central de validação

Use esta área para testar envios reais, conferir compatibilidade da versão fix e revisar exatamente qual destino e payload serão usados.

ALL0Total mapeado

VIS0Visíveis no filtro

FIX0Com correção

LOG-Último recurso

Nenhum recurso selecionado

Clique em um recurso para ver detalhes antes de enviar.

Destino normalizado-

Instância-

Fix aplicado-

Categoria-

{}

Retorno técnico

Aguardando ação.

OK-Resultado

HTTP-Status

MSG-Tipo/ação

ID-Mensagem

Endpoint-

Instância-

Destino-

Horário-

Leitura rápida

Nenhum retorno carregado.

Recurso-

Instância-

Destino-

Mensagem-

Histórico local

Últimas execuções salvas neste navegador.

ALL0Total

OK0Sucesso

ERR0Falha

LAST-Último

Filtros

Filtre por nome do recurso, status HTTP, identificador da mensagem ou resultado.

Atualizações do fix

Registro técnico das correções aplicadas no Evolution 2.3.7 e na estrutura do pacote.

2.3.7-fix.73

Pacote de correção portável

Este painel documenta o que foi alterado para que o mesmo fix possa ser aplicado em outro servidor Evolution 2.3.7 sem levar dados fixos deste ambiente.

FIX0Registros

NOWfix.73Versão atual

PKGportávelSem chave fixa

Escopo coberto Envios corrigidos, recursos no padrão Z-API, canal/newsletter, pedidos, eventos, página Testador, Manager, chat, menus fixos, login, PIN e empacotamento para atualização. Aplicação em outros servidores Os dados sensíveis ficam por servidor: Server URL, API Key Global, PIN e instância padrão são configuráveis no backend/configurações.

Buscar atualização

Área

Tipo

Documentação técnica do fix

Guia para qualquer agente entender a origem do problema, a solução aplicada e como investigar próximas correções.

guia interno

Causa raiz confirmada

A versão 2.3.7 manteve payloads antigos de botões, listas e interativos, mas passou a rodar com Baileys 6.7.6. O formato antigo com viewOnceMessage -> message -> interactiveMessage deixou de ser compatível em vários recursos. A referência funcional veio da 2.4.0-rc2, que envia interactiveMessage direto e usa native flow/additionalNodes quando necessário.

2362.3.6Formato antigo ainda entregava.

2372.3.7Mesmo formato, Baileys novo, quebrou.

2402.4.0-rc2Formato corrigido usado como base.

Erro típico API retorna 201/PENDING, mas a mensagem não chega, ou retorna 400/500 com erro de payload, download de mídia, JID ou incompatibilidade do WhatsApp. Regra principal Não confiar só no HTTP 201. Validar entrega real no WhatsApp, revisar messageType e comparar o payload com a 2.4.0-rc2 ou com o Baileys atual.

Comparação das versões

2.3.6Botões funcionavam porque o Baileys antigo ainda aceitava o wrapper viewOnceMessage em interactiveMessage.

2.3.7Atualizou dependências e manteve a estrutura antiga. Resultado: reply/lista/PIX/mídias interativas podiam retornar sucesso técnico sem entrega real.

2.4.0-rc2Remove viewOnceMessage, melhora validações CTA/PIX e envia native flow com parâmetros extras no sendMessageWithTyping.

fix 2.3.7Backport seletivo: mantém base 2.3.7, mas aplica formato corrigido, fallbacks e testador para validar cada recurso.

Onde procurar no código

Botões/listassrc/api/controllers/sendMessage.controller.ts e src/api/dto/sendMessage.dto.ts.

Baileyssrc/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts.

JID/canalsrc/utils/create-jid.ts, guards de instância e integrações de channel/newsletter.

Testadorpublic/testador.html e /testador/api em src/api/routes/index.router.ts.

Antes e depois do payload

Antes 2.3.7:
{
  viewOnceMessage: {
    message: {
      interactiveMessage: { nativeFlowMessage: {...} }
    }
  }
}

Depois fix / 2.4.0-rc2:
{
  interactiveMessage: {
    body: {...},
    footer: {...},
    nativeFlowMessage: {...}
  }
}

Soluções aplicadas

1Remover wrapper incompatível em botões e listas quando o Baileys exige interactiveMessage direto.

2Usar fallback seguro: PIX por cta_copy, botões excessivos por lista, canal em modo teste quando não há JID real.

3Hospedar mídias localmente quando URLs externas falham com fetch failed.

4Registrar version/fix_version e payload_sent em cada retorno para rastrear qual correção foi usada.

Checklist para próximos agentes

AReproduzir pelo Testador usando número real e conferir se chegou no WhatsApp, não só HTTP.

BComparar payload da 2.3.7 com 2.3.6 e 2.4.0-rc2 antes de editar.

CSe a API retornar 201 e não chegar, procurar messageType legado, wrapper incorreto, JID errado ou mídia inacessível.

DRegra obrigatória: qualquer correção deve incrementar o fix ativo, por exemplo 2.3.7-fix.22 para 2.3.7-fix.69; nunca entregar correção nova mantendo o mesmo fix.

VAtualizar o versionamento em backend, Testador, Manager quando aplicável, Atualizações, Documentação, README, manifest e pacote zip antes de concluir.

EPublicar no servidor, reiniciar serviço e validar marcador do fix no arquivo remoto.

Conteúdo consolidado de comparativo-versões.md

DescobertaA causa raiz foi a atualização do Baileys para 6.7.6 na Evolution API 2.3.7 sem adaptar os payloads interativos. O formato antigo passou a gerar retorno técnico sem entrega real ou erro 400.

Diferença crucial2.3.6 e 2.3.7 usavam viewOnceMessage -> message -> interactiveMessage. A 2.4.0-rc2 remove esse wrapper e usa interactiveMessage direto.

Mudanças 2.4.0Remove wrapper legado, cria validação hasCTAButtons, chama sendMessageWithTyping com parâmetros adicionais e adiciona comentários de compatibilidade Web/iOS/Android.

Uso recomendadoPara produção sem mudança grande, aplicar backport seletivo na 2.3.7. Para comparação, manter 2.3.6 e 2.4.0-rc2 como referências de comportamento.

Conteúdo consolidado de ANALISE_BOTOES_EVOLUTION_API.md

Arquivo centralsrc/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts, especialmente buttonMessage, toJSONString, mapType, mapKeyType e chamadas de sendMessageWithTyping.

Erro observadoTypeError: this.isZero is not a function, HTTP 400, HTTP 201/PENDING sem entrega e falhas de mídia com fetch failed ou processamento de thumbnail.

ValidaçõesReply deve respeitar limite de 3. CTA url/call/copy deve respeitar limite e não misturar com reply. PIX deve ser único e não misturar com outros tipos; quando não entregar, usar fallback copy.

Patch baseRemover viewOnceMessage de PIX e botões não-PIX, montar interactiveMessage direto, preparar mídia antes do header e enviar com buildInteractiveBizNode quando necessário.

Testes obrigatóriosReply, URL, Call, Copy, PIX, botões mistos, listas, imagem, vídeo, áudio, documento, carousel, canal/newsletter, webhook/resposta e histórico técnico do Testador.

Script consolidado comparar_botoes.py

Script original usado para extrair automaticamente buttonMessage e toJSONString das versões 2.3.6, 2.3.7 e 2.4.0-rc2. Ele fica aqui para qualquer agente reproduzir a comparação sem procurar arquivos externos.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
import re
from pathlib import Path

def extrair_funcao_buttonMessage(arquivo_path):
    with open(arquivo_path, 'r', encoding='utf-8') as f:
        conteudo = f.read()
    pattern = r'public async buttonMessage\(data: SendButtonsDto\)[^{]*\{.*?^\s{4}\}'
    match = re.search(pattern, conteudo, re.DOTALL | re.MULTILINE)
    return match.group(0) if match else None

def extrair_toJSONString(arquivo_path):
    with open(arquivo_path, 'r', encoding='utf-8') as f:
        conteudo = f.read()
    pattern = r'private toJSONString\(button: Button\): string \{.*?^\s{4}\}'
    match = re.search(pattern, conteudo, re.DOTALL | re.MULTILINE)
    return match.group(0) if match else None

arquivos = {
    'v2.3.6': 'evolution-api-2.3.6/evolution-api-2.3.6/src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts',
    'v2.3.7': 'evolution-api-2.3.7/evolution-api-2.3.7/src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts',
    'v2.4.0-rc2': 'evolution-api-2.4.0-rc2/evolution-api-2.4.0-rc2/src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts'
}

for versao, caminho in arquivos.items():
    print(f"\n{'='*80}")
    print(f"{versao} - buttonMessage")
    print('='*80)
    func = extrair_funcao_buttonMessage(caminho)
    print(func[:1500] if func else "NAO ENCONTRADA")

    print(f"\n{'='*80}")
    print(f"{versao} - toJSONString")
    print('='*80)
    func = extrair_toJSONString(caminho)
    print(func if func else "NAO ENCONTRADA")

Registro automático de impacto

Este bloco é preenchido a partir das mesmas entradas da aba Atualizações. Ao registrar um novo fix em fixUpdates, o resumo abaixo passa a refletir a documentação operacional sem remover histórico anterior.

CarregandoAs últimas correções serão listadas automaticamente.

Fontes locais da análise

Use este bloco como checklist antes de mexer em mensagens interativas, botões, canais/newsletter ou recursos que dependem do Baileys. A fonte consultada precisa aparecer no registro do fix.

Comparativodocker_evolution/comparativo-versões.md
Mostra diferenças entre 2.3.6, 2.3.7 e 2.4.0-rc2. Serve para confirmar se o comportamento veio da versão atual, de regressão ou de recurso futuro.

Análise técnicadocker_evolution/ANALISE_BOTOES_EVOLUTION_API.md
Documenta payloads, CTA, PIX, newsletter, limites do Baileys e decisões usadas para separar Suportado, Possível e teste fictício.

Script de apoioscripts/comparar_botoes.py
Reexecuta a comparação de botões e mensagens interativas. Deve ser usado quando o endpoint mudar ou quando aparecer retorno inesperado.

Fonte 2.3.6v2.3.6-source
Referência base para identificar comportamento anterior e evitar atribuir ao fix atual uma regra que já existia na versão antiga.

Fonte 2.3.7v2.3.7-source
Fonte efetiva da versão instalada. É a primeira referência para qualquer correção publicada no ambiente Conta Exata.

Fonte 2.4.0-rc2v2.4.0-rc2
Referência futura para comparar intenção de implementação. Não deve ser usada para prometer suporte real na 2.3.7 sem teste prático.

Regra de registro: ao criar novo fix, informar fonte consultada, endpoint ou payload afetado, impacto no usuário, fallback aplicado e validação executada. Não remover histórico anterior.

Configurações do testador

Controle o PIN de acesso e os dados usados para abrir o Manager neste servidor.

Seguro

Depois de salvar, use o novo PIN no próximo login. A sessão atual é renovada automaticamente.

Evolution Manager

Configure a URL e a chave que serão gravadas no Manager. Estes dados ficam salvos somente neste servidor.

Por servidor

Server URL

Use a URL pública deste Evolution. Se ficar vazio, usa a URL detectada no servidor.

API Key Global

O valor fica oculto por padrão. Clique no olho para visualizar e editar.

Caminho do Manager

Use o padrão /manager. Alterar somente se este servidor usar outro caminho.

Dados efetivos

Server URL-

API KeyMascarada

Console de validação

Entrar no testador

Categorias cobertas

Checklist operacional

Instância e conexão

Resumo do ambiente

Destino e recursos

Central de validação

Nenhum recurso selecionado

Retorno técnico

Leitura rápida

Histórico local

Filtros

Atualizações do fix

Pacote de correção portável

Documentação técnica do fix

Causa raiz confirmada

Comparação das versões

Onde procurar no código

Antes e depois do payload

Soluções aplicadas

Checklist para próximos agentes

Conteúdo consolidado de comparativo-versões.md

Conteúdo consolidado de ANALISE_BOTOES_EVOLUTION_API.md

Script consolidado comparar_botoes.py

Registro automático de impacto

Fontes locais da análise

Configurações do testador

Evolution Manager