--- title: "API de WhatsApp para helpdesk multiagente | D-API" description: "Como uma API de WhatsApp sustenta um helpdesk multiagente: filas, atribuição, SLA, status de leitura e transferência entre agentes, com um número por cliente." url: https://d-api.cloud/api-whatsapp-para-helpdesk --- Por segmento # API de WhatsApp para helpdesk: filas, SLA e vários atendentes num número Num helpdesk, a API de WhatsApp é só o cano: ela conecta o número de cada cliente da sua plataforma e entrega mensagens, leituras e quedas de conexão por webhook. Fila, atribuição, SLA e transferência continuam sendo regra do seu produto, e é assim que deve ser. Por Time de engenharia D-APIAtualizado em 24 de set de 20265 min de leitura [Falar com o time](https://d-api.cloud/#lead) ## O que muda quando o canal é WhatsApp e não e-mail Plataforma de atendimento nasceu em cima de e-mail, onde o ticket é natural: uma mensagem longa, uma resposta, um assunto. No WhatsApp o cliente manda seis mensagens curtas, um áudio e uma foto em dois minutos, e espera resposta no ritmo de conversa. O helpdesk que só "pluga" o WhatsApp no modelo de ticket entrega uma experiência ruim para o atendente e para o cliente final. Os pontos que mais geram reclamação de quem usa helpdesk com WhatsApp são sempre os mesmos: conversa caindo na fila errada, dois atendentes respondendo a mesma pessoa, SLA que não reflete a realidade e número desconectado que ninguém percebeu até o fim do dia. ## Quem faz o quê: a API e o seu helpdesk A confusão mais comum em projeto de helpdesk é esperar que a [API de WhatsApp](https://d-api.cloud/) resolva regra de atendimento. Ela não resolve, e não deveria. A divisão fica assim: | Funcionalidade do helpdesk | O que a API entrega | O que o seu produto decide | | --- | --- | --- | | Filas | Evento `messages.received` com remetente e conteúdo | Para qual fila a conversa vai, por horário, palavra-chave ou resposta de menu | | Atribuição | O `sessionId` diz de qual cliente e de qual número veio | Rodízio, carga por atendente, dono fixo da conta | | SLA | `timestamp` de cada mensagem recebida | Metas, pausas fora do expediente, alerta de estouro | | Status de leitura | Eventos `message.delivered` e `message.read` | Como exibir os ticks e se isso conta para o SLA | | Transferência | Nada muda: o número continua o mesmo | Quem assume, se leva histórico, se o cliente é avisado | | Saúde do canal | Evento `connection.status` e reconexão por API | Alerta no painel do administrador | Essa separação é o que permite trocar ou combinar tipos de conexão sem mexer nas regras. Na D-API, um cliente do helpdesk pode usar a API oficial e outro a não oficial, e o motor de filas nem percebe. ## Exemplo: um endpoint por responsabilidade Em helpdesk, vale separar os eventos por destino desde o começo. Mensagem nova vai para o serviço de roteamento, leitura vai para o serviço de status e queda de conexão vai para alertas. O modo `per_event` da configuração de webhook faz exatamente isso: ``` curl -X POST https://api.d-api.cloud/api/v1/sessions/helpdesk-cliente-318/webhook-config \ -H "Authorization: SUA_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "enabled": true, "type": "per_event", "events": { "messages.received": { "enabled": true, "webhookUrl": "https://api.seuhelpdesk.com/wa/roteamento" }, "message.delivered": { "enabled": true, "webhookUrl": "https://api.seuhelpdesk.com/wa/status" }, "message.read": { "enabled": true, "webhookUrl": "https://api.seuhelpdesk.com/wa/status" }, "connection.status": { "enabled": true, "webhookUrl": "https://api.seuhelpdesk.com/wa/alertas" } } }' ``` Com isso, um pico de leituras não atrasa a chegada de mensagens novas na fila. Se o volume da sua base for alto, a mesma configuração existe para RabbitMQ, e o helpdesk consome os eventos da fila no ritmo dele. Mais sobre formatos e reentregas em [webhook de WhatsApp](https://d-api.cloud/webhook-api-whatsapp). ## Três armadilhas de helpdesk com WhatsApp ### Conversa duplicada por reentrega O webhook é reenviado em caso de falha, com até 7 tentativas. Se o serviço de roteamento demorou para responder e o evento chegou de novo, a mesma mensagem pode abrir dois tickets. Trave pela chave do `id` da mensagem antes de qualquer outra lógica. ### Resposta dada pelo celular da empresa Na API não oficial, o número segue ativo no aparelho. Se um supervisor responde pelo celular, a mensagem chega com `fromMe` verdadeiro e precisa entrar no histórico do ticket, senão o próximo atendente responde por cima. ### SLA contado em mensagem, não em conversa Seis mensagens seguidas não são seis tickets. Agrupe mensagens do mesmo remetente numa janela curta e conte o SLA a partir da primeira, não da última. ## Roteiro para colocar WhatsApp na sua plataforma de atendimento 1. Onboarding do cliente: criar a conexão por API com o id do cliente no `sessionId` e exibir o QR Code. 2. Webhook separado por evento, com deduplicação pelo id da mensagem. 3. Agrupamento de mensagens em conversa e regra de roteamento para fila. 4. Envio de resposta, mídia e documentos pela tela do atendente. 5. Ticks de entrega e leitura, e métricas de SLA calculadas a partir dos timestamps. 6. Painel de saúde das conexões por cliente, com botão de reconectar. O passo 3 é o que diferencia um helpdesk do outro, e é onde o seu time deveria gastar tempo. A parte de manter cada número conectado e isolado dos demais fica com a D-API, com self-healing e IP próprio por conexão. Os 14 dias grátis falando com o time comercial servem justamente para validar os passos 1 e 2 com a sua base real. ## Próximos passos Se a sua plataforma também faz pré-atendimento automático, veja [chatbot de WhatsApp com IA](https://d-api.cloud/api-whatsapp-chatbot-com-ia). Se ela nasceu como CRM e está ganhando fila e SLA, a leitura complementar é [WhatsApp para CRM](https://d-api.cloud/api-whatsapp-para-crm). O modelo comercial para quem oferece WhatsApp aos próprios clientes, com uma conexão por cliente, está em [API de WhatsApp para SaaS](https://d-api.cloud/api-whatsapp-para-saas). ## Perguntas frequentes ### Vários atendentes podem responder pelo mesmo número de WhatsApp? Sim. O número fica conectado uma vez na API e todos os atendentes trabalham pela tela do seu helpdesk. Quem responde cada conversa é decidido pelo seu sistema, não pelo WhatsApp. ### O cliente final percebe quando a conversa é transferida? Não, a menos que você avise. A transferência acontece dentro do helpdesk e as mensagens continuam saindo do mesmo número. Muitas plataformas mandam uma frase curta dizendo quem assumiu, o que costuma reduzir repetição de pergunta. ### Dá para saber se o cliente leu a resposta do atendente? Sim. A API envia os eventos message.delivered e message.read para o seu webhook. O helpdesk usa esses eventos para mostrar os ticks na conversa e para medir o tempo até a leitura. ### Como medir SLA de primeira resposta com a API? Todo evento messages.received traz o timestamp da mensagem. O helpdesk grava esse horário ao abrir o ticket e fecha a contagem quando o primeiro envio de um atendente é aceito pela API. ### E se a conexão de um cliente do helpdesk cair durante o expediente? O evento connection.status avisa a mudança de estado. A D-API tenta recuperar a conexão sozinha, e o helpdesk deve mostrar um alerta ao administrador para o caso de o número ter sido desconectado no celular. ### Posso ligar um chatbot antes da fila humana? Pode. O bot recebe o mesmo webhook, responde as perguntas simples e, quando precisa de gente, o helpdesk coloca a conversa na fila com o contexto já coletado. ## Fale com nosso time 14 dias grátis pra testar e implementar, com onboarding dedicado. Resposta em até 1 dia útil. ## Continue lendo - [Por segmentoAPI de WhatsApp para clínicas](https://d-api.cloud/api-whatsapp-para-clinicas) - [Por segmentoAPI de WhatsApp para edtechs](https://d-api.cloud/api-whatsapp-para-edtech) - [Por segmentoAPI de WhatsApp para imobiliárias](https://d-api.cloud/api-whatsapp-para-imobiliarias) - [Por segmentoAPI de WhatsApp para delivery](https://d-api.cloud/api-whatsapp-para-delivery) ## Coloque WhatsApp no seu produto sem virar time de infra 14 dias grátis falando com o time comercial, com suporte de implementação num grupo de WhatsApp. [Falar com o time](https://d-api.cloud/#lead)