WaflyTutoriais › Migração no n8n

Como migrar Evolution API ou Z-API no n8n sem refazer o fluxo

Publicado em 28 de agosto de 2026 · guia técnico com rollback

Você não precisa reconstruir a automação. Duplique o workflow, transforme os payloads do fornecedor em um formato interno, mantenha a regra de negócio no meio e troque somente os nodes de entrada e saída. Valide com outro número; no corte de produção, desligue a sessão antiga antes de conectar a nova.

O que realmente muda entre as APIs

CamadaZ-APIEvolution APIWafly
AutenticaçãoID e token na URL; Client-Token da contaHeader apikeyClient-Token, instância e token
RecebimentoWebhooks POST configurados por eventoWebhook por instância ou global, com eventos selecionadosWebhooks de recebimento, entrega e conexão
n8nHTTP RequestHTTP Request ou nodes da comunidadeNode dedicado ou HTTP Request
InfraestruturaGerenciadaNormalmente self-host ou serviço de terceiroGerenciada

A documentação oficial da Z-API alerta que ID e token devem ficar no servidor, nunca no frontend. A documentação atual da Evolution mostra autenticação por apikey e webhooks com eventos como MESSAGES_UPSERT e CONNECTION_UPDATE. A migração deve tratar essas diferenças somente nas bordas do fluxo.

O desenho que evita refazer tudo

Webhook do fornecedor
Normalizar evento
Regra de negócio
Enviar pela API

O erro comum é deixar dezenas de expressões do n8n lendo diretamente campos como body.data.key.remoteJid. Quando o fornecedor muda, todas quebram. Crie um node “Normalizar WhatsApp” logo após o webhook e faça o resto do fluxo consumir apenas seu contrato interno.

Migração em 7 passos

  1. Duplique o workflow. A cópia recebe um sufixo de homologação e fica desativada até os testes.
  2. Separe configuração. URL base, instância e tokens vão para Credentials ou Variables. Não espalhe valores em cada HTTP Request.
  3. Normalize a entrada. Depois do webhook, gere sempre os mesmos campos: provedor, instância, ID da mensagem, telefone, texto, tipo e flag de grupo.
  4. Normalize a saída. Antes do envio, a regra entrega apenas phone, message e mídia opcional.
  5. Troque o transporte. Substitua o HTTP Request antigo pelo node Wafly ou pela nova chamada REST.
  6. Teste com outro número. Não tente manter o mesmo WhatsApp conectado nos dois fornecedores.
  7. Faça o corte. Desative o workflow antigo, desconecte a sessão anterior, conecte a nova e acompanhe os eventos.

Exemplo de contrato normalizado

{
  "provider": "wafly",
  "instance": "cliente-acme",
  "message_id": "3EB0...",
  "phone": "5511999999999",
  "text": "Quero falar com vendas",
  "type": "text",
  "is_group": false,
  "received_at": "2026-08-28T23:00:00Z"
}

No n8n, um Set/Edit Fields ou Code node transforma o evento recebido nesse objeto. A partir daí CRM, agente de IA, filtros e banco não precisam saber se o evento veio da Evolution, Z-API ou Wafly.

Para enviar pela Wafly via HTTP Request:

POST https://wafly.com.br/api-bridge-whats/instances/SUA_INSTANCIA/token/SEU_TOKEN/send-text
Client-Token: SEU_CLIENT_TOKEN
Content-Type: application/json

{
  "phone": "{{$json.phone}}",
  "message": "{{$json.message}}"
}

Matriz mínima antes do corte

CasoValidarResultado esperado
Texto enviadoTelefone, resposta HTTP e IDUma mensagem, um ID persistido
Texto recebidoTelefone, texto e instânciaContrato normalizado completo
MídiaTipo, URL/base64 e tamanhoFluxo não tenta tratar mídia como texto
StatusID da mensagemAtualiza o mesmo registro do envio
Evento duplicadoMesmo message_idSegunda execução é ignorada
DesconexãoInstância e alertaResponsável correto é notificado
Erro da APITimeout e resposta 4xx/5xxRetry limitado, sem loop infinito

Como executar o corte e preservar rollback

  1. Congele mudanças no workflow durante a janela.
  2. Desative o workflow antigo para impedir resposta duplicada.
  3. Desconecte o número da sessão anterior e conecte na nova API.
  4. Envie e receba uma mensagem controlada.
  5. Confirme que o CRM e os status foram atualizados.
  6. Mantenha o workflow antigo desativado por 24 horas antes de arquivá-lo.
Rollback não é duas sessões ativas. É ter credenciais, workflow e instruções documentadas para reconectar o número ao fornecedor anterior se os testes de produção falharem.

Valide a migração antes do corte

Crie uma instância de homologação na Wafly e teste o fluxo por 3 dias sem cartão.

Criar instância de testeConferir endpoints

Fontes oficiais consultadas

Perguntas frequentes

Preciso refazer o workflow inteiro?

Não. Quando entrada e saída são normalizadas, CRM, IA e regras continuam iguais. A troca acontece nas bordas.

Posso usar o mesmo número nos dois fornecedores?

Não como estratégia de teste. Use outro número em homologação; no corte, desconecte a sessão anterior antes de conectar a nova.

Como evito duplicidade?

Persista o ID da mensagem e descarte IDs já processados. Desative o workflow antigo antes de ativar produção.

Evolution API é oficial?

A Evolution atualmente suporta conexão via Baileys e também integração com a Cloud API da Meta. Verifique qual provider está configurado. Wafly e Z-API por QR são não oficiais.

Continue

Alternativa à Z-APIDecisão operacional e comparação além do n8n.Evolution self-host ou gerenciadaInfraestrutura, horas de operação e custo real.WhatsApp no n8n em 5 passosConfiguração do zero à primeira mensagem.