Usar o celular e a API no mesmo número (API não oficial): o que funciona

Sim, na API não oficial do WhatsApp você usa o celular e a API no mesmo número ao mesmo tempo: a instância entra como um aparelho conectado, e o celular continua funcionando normalmente. O que exige cuidado é a convivência — seu sistema precisa saber quando alguém respondeu pelo celular, para o bot não atropelar o atendente. Isso se resolve com o webhook de mensagens enviadas pelo próprio número, que chegam marcadas com from_me: true.

É um cenário muito comum em pequenas e médias empresas: o dono ou a equipe já atende pelo celular, e a automação chega para cuidar do repetitivo — confirmação, horário, segunda via, primeira triagem. Ninguém quer trocar de número nem abandonar o app. Este guia mostra como montar esse convívio sem mensagem duplicada e sem o bot respondendo em cima de uma conversa humana.

Por que funciona na API não oficial

A instância da API não oficial se conecta ao número do mesmo jeito que o WhatsApp Web: você escaneia o QR Code (ou digita um código de pareamento) em Aparelhos conectados. A partir daí, o número tem dois "aparelhos" ativos — o celular e a instância — e os dois enxergam as mesmas conversas.

Na prática:

• Mensagem que a API envia aparece no celular, na conversa certa.
• Mensagem que o cliente manda chega no celular e no webhook da API.
• Mensagem que o atendente digita no celular pode chegar ao seu sistema, se você pedir.

A camada não oficial da WAME não é afiliada, endossada ou suportada pelo WhatsApp ou pela Meta. O uso é de responsabilidade de quem envia.

Na API oficial, esse convívio tem nome próprio — Coexistência — e regras específicas; o assunto está em API oficial sem perder o celular. Na não oficial, ele é o estado natural da conexão.

Passo 1: receba também o que sai pelo celular

Por padrão, o que interessa ao bot são as mensagens que chegam. Para enxergar o que a equipe responde pelo celular, configure também o webhookMessageFromMe:

curl -X PUT "https://us.api-wa.me/SUA_KEY/instance" \
  -H "Content-Type: application/json" \
  -d '{
    "allowWebhook": true,
    "allowNumber": "all",
    "webhookMessage": "https://seu-servidor.com/webhook/wame",
    "webhookMessageFromMe": "https://seu-servidor.com/webhook/wame",
    "webhookFormat": "meta"
  }'

As mensagens enviadas pelo próprio número chegam no mesmo envelope das recebidas, com uma diferença: o campo from_me: true. Isso vale para o que o atendente digitou no celular e também para o que a própria API enviou — o que é ótimo para auditoria, mas exige um cuidado que veremos no passo 3.

Apontar os dois webhooks para a mesma URL simplifica: um só handler, que decide pelo from_me.

Passo 2: separe as três origens

No seu handler, toda mensagem cai em uma de três categorias:

function classificar(body, idsEnviadosPeloBot) {
  const msg = body?.entry?.[0]?.changes?.[0]?.value?.messages?.[0];
  if (!msg) return null;

  if (!msg.from_me) return { origem: 'cliente', msg };

  // Eco de mensagem enviada pelo próprio número.
  if (idsEnviadosPeloBot.has(msg.id)) return { origem: 'bot', msg };

  // from_me que o bot não enviou: alguém respondeu pelo celular.
  return { origem: 'humano', msg };
}

A chave está em guardar os ids das mensagens que o bot enviou. A resposta do envio traz o id da mensagem no campo id; registre-o num conjunto (ou no Redis, com expiração de algumas horas). Quando o eco chega com from_me: true, você sabe que foi o bot. Qualquer outro from_me foi uma pessoa.

Em 1:1, o from do eco identifica a conversa. Em grupo, use o group_id, que só aparece quando a mensagem é de grupo.

Passo 3: pause o bot quando o humano assume

A regra que evita quase toda trapalhada é simples: se um humano respondeu naquela conversa, o bot sai de cena por um tempo.

const pausas = new Map(); // conversa → até quando o bot fica calado
const PAUSA_MS = 2 * 60 * 60 * 1000; // 2 horas, ajuste ao seu atendimento

app.post('/webhook/wame', async (req, res) => {
  res.sendStatus(200);

  const item = classificar(req.body, idsEnviadosPeloBot);
  if (!item) return;

  const conversa = item.msg.group_id ?? item.msg.from;

  if (item.origem === 'humano') {
    pausas.set(conversa, Date.now() + PAUSA_MS);
    return;
  }
  if (item.origem === 'bot') return; // eco do próprio bot: ignore

  const pausadoAte = pausas.get(conversa) ?? 0;
  if (Date.now() < pausadoAte) return; // humano no comando

  await responderComBot(item.msg);
});

Três detalhes que fazem diferença:

• Ignorar o eco do bot evita o loop clássico, em que o bot lê a própria resposta como se fosse do cliente.
• A pausa renova a cada resposta humana. Enquanto o atendente conversa, o bot continua calado.
• Em produção, guarde a pausa num lugar persistente (banco ou Redis). Um Map em memória some no restart, e o bot volta a falar no meio de uma conversa humana.

Se preferir um controle explícito, combine uma palavra que o atendente digita para devolver a conversa ao bot — por exemplo, uma mensagem que comece com #bot — e trate isso no mesmo handler.

Passo 4: use etiquetas para a equipe enxergar o estado

Quem atende pelo celular não vê o seu banco de dados. Mas vê etiquetas. Se o número usa o WhatsApp Business, as etiquetas criadas pela API são sincronizadas com o app:

# Criar a etiqueta (uma vez)
curl -X POST "https://us.api-wa.me/SUA_KEY/labels" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Precisa de humano", "color": 1 }'

# Marcar a conversa quando o bot passa a vez
curl -X POST "https://us.api-wa.me/SUA_KEY/labels/ID_DA_ETIQUETA" \
  -H "Content-Type: application/json" \
  -d '{ "to": "5511999999999" }'

# Tirar a marca quando resolver
curl -X DELETE "https://us.api-wa.me/SUA_KEY/labels/ID_DA_ETIQUETA/chat/5511999999999"

Assim o fluxo fica visível no próprio celular: o bot triou, marcou "Precisa de humano", o atendente filtra por essa etiqueta e responde. Mais ideias em labels na API do WhatsApp.

Passo 5: cuide do "lido"

Quando a API marca uma mensagem como lida, o cliente vê os tiques azuis — e o atendente, no celular, vê a conversa como lida também. Isso pode esconder uma conversa que ninguém humano olhou.

Se a equipe usa "não lidas" como fila de trabalho, deixe a leitura automática desligada na instância e marque como lido só o que o bot resolveu de fato. A leitura é configurada com o parâmetro markMessageRead no PATCH /{key}/instance, e uma conversa pode voltar a ficar como não lida com PATCH /{key}/chat usando a ação markRead com valor false.

Como fica o dia a dia

Um fluxo típico numa loja ou clínica:

1. Cliente escreve às 22h. O bot responde, tira dúvidas simples e agenda.
2. Cliente pede algo fora do roteiro. O bot avisa que um atendente vai responder e marca a etiqueta.
3. De manhã, a atendente abre o celular, filtra a etiqueta e responde.
4. O webhook recebe a resposta dela com from_me: true, e o bot pausa naquela conversa.
5. Resolvido, a atendente tira a etiqueta. Na próxima mensagem do cliente, depois da pausa, o bot volta a atender.

Ninguém trocou de número, ninguém instalou painel novo e o cliente nunca recebeu duas respostas.

Quando partir para multiatendimento

O convívio celular + API funciona muito bem com uma ou duas pessoas atendendo. Quando a equipe cresce, um celular só vira gargalo: todo mundo querendo o mesmo aparelho, sem saber quem está falando com quem. Aí vale um painel com vários atendentes no mesmo número, atribuição de conversa e transferência — o desenho está em vários atendentes no mesmo número, e há integração pronta com o Chatwoot.

E o risco de bloqueio?

Um número usado por gente de verdade e por um bot que responde quem escreveu é o perfil mais saudável que existe. Na WAME, cada envio da API já sai com tempo humano — online, "digitando…" proporcional ao texto, envio —, então a resposta automática não destoa das respostas da equipe. Com esse uso, a taxa de bloqueio é muito baixa.

O que continua sendo risco é o de sempre, e a WAME não apoia: mandar para quem não pediu, repetir a mesma mensagem para muita gente, volume fora do padrão. Os detalhes estão em o que realmente derruba um número.

Conclusão

Celular e API convivem no mesmo número desde o primeiro minuto na API não oficial, porque a instância é só mais um aparelho conectado. O trabalho está em fazer o sistema enxergar a equipe: receber as mensagens com from_me: true, separar o eco do bot da resposta humana e pausar o bot na conversa em que alguém assumiu. Com etiquetas e um cuidado com o "lido", a equipe continua atendendo pelo app e a automação cuida do resto. A referência dos webhooks está na documentação, e o panorama geral em vantagens da API não oficial.