Atualizado em 25/10/2026
Para ter vários atendentes no mesmo número de WhatsApp, há dois caminhos: os aparelhos conectados do app WhatsApp Business, que têm limite de dispositivos, ou a API oficial, em que o número é operado por um sistema e os atendentes trabalham numa caixa de entrada compartilhada, sem limite de pessoas imposto pela Meta. Com a API, a distribuição de conversas, o histórico e as permissões ficam no seu software. Com a coexistência, dá até para manter o celular funcionando junto.
Os limites do app WhatsApp Business
O app foi feito para uso manual. Segundo a Central de Ajuda do WhatsApp, uma conta business conecta até quatro dispositivos; o recurso de múltiplos atendentes eleva esse limite para até 10, conforme os benefícios de assinaturas como o Meta Verified. Isso resolve uma loja pequena, mas cria problemas quando o time cresce:
- Todos veem tudo. Não há fila, nem conversa “minha” e “sua”. Dois atendentes respondem o mesmo cliente, ou nenhum responde.
- Sem métricas por pessoa. Não dá para saber quem respondeu, em quanto tempo, nem quantas conversas cada um resolveu.
- Dependência do celular principal. Se o aparelho principal fica sem uso por cerca de 14 dias, os dispositivos conectados são desconectados.
- Sem integração. O app não conversa com o CRM, o ERP ou o bot.
Como a API resolve: o número vira um sistema
Na API oficial do WhatsApp, o número não está num celular. Toda mensagem recebida chega ao seu servidor por webhook e toda resposta sai por uma chamada HTTP. O “atendente” não é um dispositivo conectado ao WhatsApp, é um usuário do seu sistema. Por isso a Meta não limita quantas pessoas atendem: o limite é o do seu software.
| Aspecto | App com aparelhos conectados | API com caixa de entrada compartilhada |
|---|---|---|
| Número de atendentes | Até 4 dispositivos (até 10 com o recurso de múltiplos atendentes) | Definido pelo seu sistema |
| Distribuição | Manual | Automática, por regra |
| Histórico | No aparelho | No seu banco de dados |
| Métricas por atendente | Não | Sim, a partir dos eventos |
| Bot e IA | Não nativo | Integrado ao mesmo fluxo |
| Permissões | Quem tem o aparelho vê tudo | Por equipe, fila ou função |
A arquitetura de uma caixa de entrada compartilhada
Um multiatendimento com a API tem cinco peças:
- Receptor de webhook. Recebe os eventos da Meta, responde
200rápido e coloca o evento numa fila. Não processe nada pesado aqui. - Processador. Lê a fila, grava mensagem e status no banco, abre ou reabre a conversa e chama o motor de distribuição.
- Motor de distribuição. Decide quem atende: bot, fila de um departamento ou atendente específico.
- Interface do atendente. Lista de conversas atribuídas, histórico e campo de resposta, atualizada em tempo real (WebSocket ou similar).
- Envio. Uma camada única que chama a API, registra o
wamiddevolvido e trata erros.
Dois detalhes do webhook mudam o desenho. A visão geral de webhooks diz que a Meta tenta reenviar eventos não confirmados por até 7 dias e que isso pode gerar notificações duplicadas. Então:
- Deduplique pelo
idda mensagem (wamid). Uma restrição única no banco resolve. - Não confie na ordem de chegada. Ordene as mensagens pelo
timestampdo evento, não pela hora em que o webhook chegou.
O artigo sobre webhooks da API do WhatsApp mostra a estrutura completa dos eventos.
Estados da conversa
Uma conversa de atendimento precisa de estados claros. Um modelo simples:
| Estado | Significado | Quem age |
|---|---|---|
bot | Bot ou mensagem automática tratando | Sistema |
fila | Aguardando atendente de um departamento | Motor de distribuição |
atribuida | Um atendente é dono da conversa | Atendente |
aguardando_cliente | Atendente respondeu, falta o cliente | Sistema monitora a janela de 24 h |
encerrada | Atendimento concluído | Reabre se o cliente escrever de novo |
O estado aguardando_cliente importa por causa da janela de 24 horas: se o cliente demora a responder e a janela fecha, o atendente só consegue retomar com template.
Regras de distribuição
Não existe regra melhor para todo caso. As mais usadas:
| Regra | Como funciona | Quando usar |
|---|---|---|
| Rodízio (round robin) | Próximo atendente disponível da lista | Times homogêneos, demanda parecida |
| Menor carga | Quem tem menos conversas abertas | Atendimentos de duração variável |
| Por departamento | Bot pergunta o assunto e manda para a fila certa | Vendas, suporte e financeiro separados |
| Fidelidade | Cliente volta para o último atendente, se disponível | Vendas consultivas, carteira de clientes |
| Manual (puxar da fila) | Atendente escolhe a próxima conversa | Times pequenos, casos complexos |
Na prática, combine: o bot ou a mensagem de boas-vindas pergunta o assunto, a conversa vai para a fila do departamento, e dentro da fila vale menor carga com fidelidade para clientes recorrentes.
Exemplo: atribuição sem conflito em PostgreSQL
O erro mais comum é dois atendentes pegarem a mesma conversa. Com FOR UPDATE SKIP LOCKED, cada transação trava a conversa que está atribuindo e ignora as que outra transação já pegou:
-- Atribui a conversa mais antiga da fila ao atendente com menos conversas abertas
WITH proxima AS (
SELECT id
FROM conversas
WHERE estado = 'fila' AND departamento = 'suporte'
ORDER BY entrou_na_fila_em
LIMIT 1
FOR UPDATE SKIP LOCKED
),
atendente AS (
SELECT a.id
FROM atendentes a
LEFT JOIN conversas c ON c.atendente_id = a.id AND c.estado = 'atribuida'
WHERE a.online AND a.departamento = 'suporte'
GROUP BY a.id, a.max_simultaneas
HAVING COUNT(c.id) < a.max_simultaneas
ORDER BY COUNT(c.id)
LIMIT 1
)
UPDATE conversas
SET estado = 'atribuida', atendente_id = (SELECT id FROM atendente), atribuida_em = now()
WHERE id = (SELECT id FROM proxima)
AND EXISTS (SELECT 1 FROM atendente)
RETURNING id, atendente_id;Rode isso quando uma conversa entra na fila e quando um atendente fica livre. O campo max_simultaneas evita que alguém receba mais conversas do que consegue responder.
Boas práticas de operação
- Identifique quem responde. Prefixe a mensagem com o nome do atendente (“Ana:“). O cliente sabe com quem fala e a troca de atendente fica transparente.
- Transferência com contexto. Ao passar a conversa, inclua uma nota interna. O cliente não deve repetir tudo.
- Marque como lida só quando alguém leu. O status
readmostra os dois tiques azuis para o cliente; envie quando o atendente abrir a conversa, não quando o webhook chegar. - Um único ponto de envio. Bot, atendentes e automações devem sair pela mesma camada, para respeitar o throughput do número e registrar tudo.
- Permissões mínimas. Atendente vê a própria fila; supervisor vê o time. O guia de segurança da conta business trata de acessos ao portfólio e tokens.
- Meça. Tempo de primeira resposta, tempo de atendimento e satisfação por atendente e por fila. Veja métricas de atendimento no WhatsApp.
Coexistência: o celular continua funcionando
Com a coexistência, o mesmo número fica no app WhatsApp Business e na API ao mesmo tempo. Isso permite que o dono continue respondendo pelo celular enquanto o time usa a caixa de entrada. Segundo a documentação de coexistência:
- Mensagens enviadas pelo app chegam ao seu sistema pelo webhook
smb_message_echoes. Mostre-as no histórico da conversa, ou o atendente não vai saber que o cliente já foi respondido. - O app aceita até quatro dispositivos acompanhantes. Mensagens enviadas de acompanhantes não suportados (como o WhatsApp para Windows) não geram webhook e não aparecem no seu sistema.
- O throughput de números em coexistência é fixo em 20 mensagens por segundo.
- Ferramentas do app como respostas rápidas, etiquetas, mensagens de saudação e de ausência não são suportadas na Cloud API.
- Se o aparelho principal ficar inativo por cerca de 14 dias, a Meta envia um
account_updatecomPARTNER_REMOVEDe a conexão com a API cai.
Para multiatendimento, a regra prática é: o celular vira mais um “atendente”, e o seu sistema precisa tratar as mensagens dele como tal. O artigo o que sincroniza na coexistência detalha cada item.
Como fazer isso com a Vectalk
A Vectalk é a camada de API: entrega os webhooks da Meta no seu sistema e envia as respostas pela Cloud API oficial. Você pode registrar várias URLs por instância com POST /api/webhooks (por exemplo, a caixa de entrada e o CRM recebendo o mesmo evento), enviar com POST /api/messages e marcar como lida com o mesmo endpoint, usando status: "read". A Vectalk oferece coexistência, então o número pode continuar no app. A caixa de entrada e as regras de distribuição são do seu software. Documentação em docs.vectalk.com.br e cadastro em apps.vectalk.com.br/register.
Se a ideia é colocar um bot antes dos atendentes, veja também chatbot com IA no WhatsApp e agendamento automático com IA.
Perguntas frequentes
Quantos atendentes posso ter no mesmo número com a API?
A Meta não limita o número de atendentes na API, porque eles não são dispositivos do WhatsApp, são usuários do seu sistema. O limite prático está no seu software e na capacidade de envio do número.
Posso usar o WhatsApp Web junto com a API?
Só com coexistência, e o WhatsApp Web entra como dispositivo acompanhante do app. As mensagens enviadas por ele chegam ao seu sistema pelo webhook smb_message_echoes. Sem coexistência, o número registrado na API não fica disponível no app nem no WhatsApp Web.
Como evitar que dois atendentes respondam o mesmo cliente?
Atribua a conversa a um dono antes de mostrar o campo de resposta, com trava no banco (como o FOR UPDATE SKIP LOCKED do exemplo). Os demais veem a conversa como somente leitura.
O cliente vê o nome do atendente?
O cliente vê o nome de exibição da empresa. Se quiser mostrar quem está atendendo, inclua o nome no texto da mensagem.
Preciso de um número por departamento?
Não. Um número com filas por departamento costuma ser mais simples para o cliente. Números separados fazem sentido para marcas ou operações diferentes.
Fontes oficiais consultadas em 25/10/2026: Visão geral de webhooks, Coexistência: onboarding de usuários do app WhatsApp Business, Central de Ajuda do WhatsApp: múltiplos atendentes, Docs da Vectalk: webhooks, Docs da Vectalk: marcar como lida.