Skip to main content
O Wabox mantém o formato de rota, os conceitos (instância, token, header Client-Token, webhooks por tipo, fila) e, na maioria dos casos, os nomes de endpoint da z-api, então quem migra muda o mínimo. A principal diferença é que os nomes usam snake_case em tudo.

O que não muda

  • A rota continua /instances/{instance_id}/token/{token}/<endpoint>, e só o host passa a ser api.wabox.me.
  • O header Client-Token tem o mesmo papel: um segundo segredo, no header, exigido em todas as instâncias da conta. No Wabox o valor é uma API key com a permissão instances:operate. Mantenha o nome do header e troque só o valor. Veja abaixo.
  • Os webhooks por tipo (received, delivery, message_status, instance_status, chat_presence) e o campo momment, mantido de propósito.
  • O envio continua assíncrono. A resposta imediata traz o id, e o resultado chega no delivery.
  • Os nomes da maioria dos endpoints, como send-text, send-image, send-button-list, send-option-list, send-carousel, qr-code, status, phone-exists, queue…
  • Vários endpoints da z-api continuam funcionando como alias (/create-group, /profile-picture, /modify-chat, /tags, /send-button-actions…). Veja a coluna “Alias aceito” na tabela de rotas.

O que muda

Os nomes passam de camelCase para snake_case. Os mais usados:A lista completa está na tabela de rotas.

Client-Token

Na z-api, o token de segurança da conta vai no header Client-Token. No Wabox esse papel é das API keys do workspace, e o header Client-Token continua aceito nas rotas de instância como alias de Authorization: Bearer:
  1. No painel, em Segurança › API keys, crie uma key com a permissão instances:operate.
  2. Coloque o valor dela onde o seu código hoje coloca o Client-Token da z-api. O nome do header não muda.
  3. Se quiser que o header seja obrigatório (como o token de segurança ativado na z-api), ligue “Exigir API key nas rotas de instância”. Desligado, que é o padrão, o header é ignorado e só o token da URL autentica.
Diferente da z-api, o workspace pode ter várias keys (uma por sistema, revogáveis uma a uma, o que permite trocar sem downtime). A key só aparece uma vez, ao ser criada. Os erros são 401 api_key_required (header ausente ou key inválida) e 403 insufficient_scope (key sem instances:operate). Em código novo, prefira Authorization: Bearer wbx_key_…. A Account API só aceita Authorization: Bearer.

Migrando sem parar

1

Crie a instância no Wabox e conecte o número

Um número só pode estar vinculado a uma sessão web por provedor, mas pode ter vários aparelhos vinculados. Você pode conectar o mesmo número no Wabox enquanto a z-api ainda está ativa e comparar os webhooks lado a lado.
2

Aponte os webhooks para um endpoint novo

Faça o seu handler aceitar os dois formatos (ou converta o payload do Wabox para o formato antigo com um adaptador de 20 linhas). Compare por alguns dias.
3

Troque os envios

Mude o host e os nomes de campos. Se você envia Client-Token, troque o valor por uma API key do Wabox. Se você usa alguma biblioteca ou nó no-code apontando para a z-api, o HTTP genérico resolve.
4

Desligue a instância antiga

Remova o aparelho da z-api em “Aparelhos conectados” no celular. Duas sessões ativas no mesmo número dividem os eventos recebidos entre si sem problema, mas não faz sentido pagar duas.

Adaptador de payload (exemplo)

Se você quer trocar o host hoje e mexer no código depois:
Trate isso como ponte temporária, porque o formato do Wabox é o que evolui e ganha campos novos.