Atendimento: mantendo a conversa no mesmo número

Cenário clássico: você tem vários números rotacionando e um cliente inicia uma conversa. No seu sistema (CRM/atendimento) abre-se um ticket. Como garantir que toda a interação aconteça no mesmo número que iniciou a conversa?

Há duas formas — escolha a que preferir (ou use as duas).

1. Afinidade automática (sticky) — recomendado

Por padrão, quando você envia sem instance_id e sem pool_id, o bZapper reusa automaticamente o número que já conversa com aquele destinatário. Ou seja: respondeu para quem te mandou mensagem → vai pelo mesmo número, sempre.

# Resposta a um cliente: nem precisa dizer o número.
curl -X POST https://api.bzapper.com.br/messages/text \
  -H "Authorization: Bearer bz_live_..." -H "Content-Type: application/json" \
  -d '{"to":"+5511988887777","body":"Oi! Como posso ajudar?"}'
# → vai pelo mesmo número que já fala com +5511988887777

Como funciona por baixo:

• O bZapper resolve o to para o JID canônico do WhatsApp (corrige o 9º dígito brasileiro e o @lid).
• Procura a conversa existente com esse contato e usa aquele número, se estiver conectado.
• Se não houver conversa anterior, cai na rotação normal (e a partir daí aquele número fica "grudado" naquele contato).

Para forçar a rotação (ex.: disparo/broadcast, onde você quer distribuir):

{ "to": "+5511988887777", "body": "Promoção!", "sticky": false }

Você envia com…	O que acontece
instance_id	usa exatamente aquele número (ignora tudo)
pool_id	rotaciona dentro do pool
nada (padrão)	sticky: reusa o número da conversa; se não houver, rotaciona
sticky: false	força rotação (broadcast)

2. Fixar você mesmo (controle total)

Se preferir controlar no seu sistema, o contrato é simples — e é o que toda a indústria faz (igual ao Twilio):

1. A entrada te diz o número. Toda mensagem recebida dispara o webhook message.received (e o SSE) com o instance_id que a recebeu.
2. Você guarda o vínculo conversa → instance_id no seu banco ao abrir o atendimento.
3. Toda resposta vai com instance_id daquele atendimento — o número nunca muda.

// webhook message.received (resumo)
{
  "type": "message.received",
  "instance_id": "492e6b46-0c5f-4727-96e3-6f9f5e4f93e8",  // ← guarde este
  "payload": { "from": "[email protected]", "body": "Olá" }
}

# Responder fixando o número:
curl -X POST https://api.bzapper.com.br/messages/text \
  -H "Authorization: Bearer bz_live_..." -H "Content-Type: application/json" \
  -d '{"to":"+5511988887777","instance_id":"492e6b46-...","body":"Resposta"}'

Passar instance_id sempre vence a rotação: o seletor devolve aquele número direto, sem nenhuma checagem de rotação/aquecimento.

Reconstruindo o vínculo

A qualquer momento dá pra recuperar qual número fala com quem:

• GET /conversations?instance_id=<id> — lista as conversas de cada número.
• Cada mensagem guarda o instance_id e o chat_jid (JID canônico).

Resumindo

• Quer simplicidade? Não mande instance_id — o sticky cuida disso.
• Quer controle? Capture o instance_id do webhook de entrada e use nas respostas.
• Disparo/broadcast? Mande sticky: false ou use um pool_id.