No atendimento, o WhatsApp é onde o cliente já está. Com a API do zapon, você traz cada conversa para dentro do seu sistema: toda mensagem recebida vira um evento que chega ao seu servidor, e toda resposta sai por uma chamada REST simples — a base de um help desk, um chatbot ou um time de atendentes humanos.
Atender pelo WhatsApp manualmente, de um celular, funciona até o ponto em que o volume cresce. Aí começam os problemas conhecidos: mensagens que se perdem, ninguém sabe quem respondeu o quê, não há histórico organizado e é impossível escalar para vários atendentes. A solução é parar de tratar o WhatsApp como um aplicativo e passar a tratá-lo como um canal programável. É exatamente isso que a API de WhatsApp para atendimento do zapon entrega: uma camada REST que coloca cada conversa sob o controle do seu software.
O modelo é direto e tem só duas direções. Na entrada, cada mensagem que o cliente envia chega ao seu sistema como um evento, entregue por webhook. Na saída, cada resposta que você quer mandar — seja de um atendente, de um chatbot ou de uma automação — sai por uma chamada à API REST. Com essas duas peças você monta qualquer fluxo de atendimento: um bot que responde 24 horas, um roteamento que distribui conversas entre atendentes, respostas rápidas padronizadas e até vários números separados por setor ou unidade. Este guia mostra o caminho completo, do primeiro número conectado até um atendimento de duas vias rodando em produção, com os endpoints, headers e payloads reais da plataforma.
Um atendimento de duas vias dentro do seu próprio sistema: cada mensagem recebida do cliente chega como evento via webhook, e cada resposta sai por uma chamada REST à API. Com isso você cria chatbots, roteia conversas para atendentes humanos, dispara respostas rápidas e opera múltiplos números separados por setor ou unidade.
Ao final deste guia você terá a estrutura básica de um atendimento centralizado no seu software, formada por quatro blocos que se combinam:
Tudo isso roda sobre números de WhatsApp comuns. Não há fila de aprovação da Meta, não há templates obrigatórios, não há custo por mensagem. Cada número se conecta por QR Code, exatamente como o WhatsApp Web, e passa a ser pilotado pela API do seu sistema de atendimento.
Três coisas: uma conta no zapon (14 dias grátis, sem cartão) com pelo menos uma conexão de WhatsApp ativa, um sistema seu (ou um endpoint) capaz de receber requisições HTTP para o webhook, e um número de WhatsApp dedicado ao atendimento. Nenhuma conta de API oficial da Meta é necessária.
Antes de integrar, garanta que você tem:
Você não precisa de conta na Meta, não precisa do WhatsApp Business API oficial e não precisa cadastrar templates. O zapon conversa diretamente com o WhatsApp do número que você conectar — o mesmo número que seus clientes já usam para falar com você.
No painel do zapon, crie uma conexão e leia o QR Code com o WhatsApp do número de atendimento (ou use o código de pareamento). Assim que a conexão ficar online, copie o token dela — é esse token que autentica todas as chamadas de API que o seu sistema fará para responder os clientes.
Antes de qualquer integração, o número precisa estar conectado e a conexão precisa ter um token. Esse token é a chave que o seu sistema vai usar para falar com a API e enviar as respostas do atendimento.
Dentro do painel do zapon, crie uma nova conexão. Cada conexão representa um número de WhatsApp e tem o seu próprio token — uma string única que autentica as requisições daquele número. Copie esse token e guarde-o com cuidado: no seu sistema, ele entra como um header chamado token (não é Authorization, não é Bearer). Trate-o como uma senha, porque quem tem o token consegue enviar mensagens em nome do seu número de atendimento.
Se o seu atendimento é dividido por setores ou unidades, crie uma conexão para cada número. Cada token corresponde a um número específico, então o seu sistema escolhe de qual número a resposta sai simplesmente trocando o header — voltaremos a isso na seção de múltiplos atendentes e setores.
Com a conexão criada, falta colocá-la online. Há dois caminhos:
Assim que o WhatsApp confirma, a conexão muda para o status online no painel. A partir daí o número está pronto para receber as mensagens dos clientes e enviar as respostas pela API. Importante: depois de conectado pela API, evite usar o mesmo número pela interface do celular para responder manualmente em paralelo — escolha um caminho para não confundir o histórico e o controle das conversas.
Cadastre uma URL do seu sistema na seção Webhook da conexão, no painel do zapon, marcando o evento de mensagem recebida. A partir daí, cada mensagem que o cliente envia ao número de atendimento chega ao seu endpoint como uma requisição POST, com quem mandou e o conteúdo — pronta para virar um ticket, um registro ou um gatilho de resposta.
O atendimento começa quando o cliente fala. Por isso, a primeira peça a montar é a entrada: o caminho pelo qual a mensagem do cliente sai do WhatsApp e chega ao seu sistema. Isso é feito com um webhook — o zapon entrega cada evento (mensagem recebida, status de entrega, leitura, etc.) via POST na URL que você indicar.
No seu software, crie uma rota que aceite requisições POST e devolva rapidamente um 200 OK. É nessa rota que o zapon vai bater a cada mensagem recebida. O corpo da requisição traz os dados do evento — o número do remetente, o texto da mensagem, o tipo de conteúdo e um identificador — para a sua aplicação processar. Uma boa prática é registrar a mensagem (em banco) antes de qualquer lógica, para nunca perder uma conversa, e só então decidir o que fazer com ela.
Logo após receber, é comum aplicar um filtro: processe apenas as mensagens recebidas de clientes e ignore eventos que não interessam — por exemplo, mensagens que o próprio número enviou ou status de leitura, caso o seu fluxo não precise deles. Esse filtro evita loops e ruído no atendimento.
De volta ao painel do zapon, abra a sua conexão e localize a seção Webhook. Lá você:
Feito isso, mande uma mensagem de teste para o número de atendimento: o seu endpoint é acionado na hora e recebe os dados da mensagem. É assim que se traz a conversa para dentro do sistema sem polling e sem gambiarra — cada mensagem recebida vira, de fato, um evento na sua aplicação.
Faça uma requisição POST para https://api.zapon.dev/chat/send/text, com o header token da sua conexão e um body JSON contendo Phone (o número do cliente) e Body (o texto da resposta). A API entrega a mensagem ao cliente e devolve um JSON com success e o id da mensagem.
Com a mensagem do cliente já dentro do seu sistema, falta o outro lado: a resposta. Toda mensagem que sai do atendimento — de um humano, de um bot ou de uma automação — é uma chamada à API de envio de texto do zapon. É uma única requisição, fácil de disparar de qualquer linguagem ou framework.
O endpoint é POST https://api.zapon.dev/chat/send/text. A autenticação é um único header chamado token, cujo valor é o token da conexão que você copiou no Passo 1 (não é Bearer, não é OAuth). O corpo é um JSON com dois campos: Phone, o número do cliente em formato internacional só com dígitos (DDI + DDD + número, ex.: 5511977776666), e Body, o texto da resposta. Normalmente o Phone da resposta é o mesmo remetente que chegou no webhook — você só ecoa de volta para quem falou.
POST https://api.zapon.dev/chat/send/text token: SEU_TOKEN Content-Type: application/json { "Phone": "5511977776666", "Body": "Recebemos sua mensagem! Já vamos te atender." }
Ao receber a chamada, a API entrega a mensagem ao cliente e responde com um JSON confirmando o envio e trazendo o identificador da mensagem:
{
"success": true,
"data": {
"id": "3EB0…"
}
}Esse id é útil no atendimento: você pode salvá-lo junto ao ticket ou à thread da conversa para rastrear cada resposta enviada e, mais tarde, casá-lo com os eventos de entrega e leitura, se você os assinou no webhook. Com a entrada (Passo 2) e a saída (Passo 3) prontas, você já tem o ciclo completo do atendimento: ouvir e responder.
Una os dois passos anteriores: receba a mensagem do cliente pelo webhook, passe o texto por uma lógica de decisão (regras, menu ou uma IA) e responda com a chamada à API. Esse ciclo de ouvir, decidir e responder, repetido a cada mensagem, é todo o funcionamento de um chatbot.
Um chatbot de atendimento nada mais é do que o fluxo de entrada e o de saída ligados por uma camada de decisão. O webhook recebe a mensagem, a sua lógica olha o conteúdo e escolhe a resposta, e a API devolve essa resposta ao cliente. O ciclo se repete a cada mensagem, mantendo, se preciso, o estado da conversa (em que etapa do menu o cliente está, quais dados ele já forneceu).
A camada de decisão pode ser tão simples quanto um menu numerado: a mensagem chega, o seu código compara o texto com opções conhecidas ("1 para suporte, 2 para vendas") e responde com o próximo passo. Para casos mais ricos, essa camada pode ser uma IA — você manda o texto do cliente para um modelo de linguagem, recebe a resposta gerada e a envia de volta pela API. Em ambos os casos, a forma de receber e de responder é a mesma; o que muda é só o miolo da decisão.
Um padrão comum e eficiente é o atendimento híbrido: o bot resolve as perguntas frequentes automaticamente e, quando detecta que o caso precisa de um humano (ou quando o cliente pede), aciona o roteamento para um atendente. Assim você reduz a carga sem perder o toque humano nos casos que importam.
Mesmo antes de qualquer lógica, uma boa prática de atendimento é confirmar ao cliente que a mensagem chegou. Assim que o webhook dispara, você pode responder na hora com um acuse simples, ganhando tempo para o processamento ou para o atendente assumir:
POST https://api.zapon.dev/chat/send/text token: SEU_TOKEN { "Phone": "5511977776666", "Body": "Olá! Recebemos sua mensagem e já estamos verificando. 🙂" }
A partir daí, o bot pode seguir com o menu, com a resposta da IA ou com o encaminhamento para um atendente humano — tudo usando a mesma chamada de envio, só trocando o Body.
A API não limita atendentes: você modela a equipe e o roteamento dentro do seu sistema, decidindo quem responde cada conversa. Para separar por setor ou unidade, conecte um número de WhatsApp para cada um — cada número tem o seu próprio token e webhook, e você escolhe de qual número a resposta sai trocando o header token.
Quando o atendimento cresce, surgem duas necessidades: distribuir as conversas entre várias pessoas e separar os canais por área. A API atende as duas, mas de formas diferentes.
A API do zapon não tem o conceito de "atendente" — e isso é uma vantagem, porque dá liberdade total. Os atendentes vivem no seu sistema: você modela usuários, filas e atribuição como quiser. Quando uma mensagem chega pelo webhook, a sua lógica decide para qual atendente aquela conversa vai (por rodízio, por disponibilidade, por assunto) e mostra a conversa na tela dele. Quando o atendente responde, o seu sistema dispara a chamada à API — todas saindo do mesmo número conectado, com o mesmo token. Do lado do cliente, é sempre o número da empresa respondendo; quem está por trás é controlado internamente pelo seu software.
Para separar de verdade os canais — um número para vendas, outro para suporte, outro para cada unidade —, conecte vários números, um por setor. Cada conexão tem o seu próprio token e o seu próprio webhook. O seu sistema sabe de qual número a mensagem chegou (pelo webhook daquela conexão) e, ao responder, usa o token correspondente para que a resposta saia pelo número certo. Trocar o setor é, na prática, trocar o header:
POST https://api.zapon.dev/chat/send/text token: TOKEN_DO_SUPORTE { "Phone": "5511977776666", "Body": "Aqui é o suporte do zapon. Como posso ajudar?" }
Esse desenho escala bem: cada número custa R$ 27 por mês com mensagens ilimitadas, então você dimensiona a operação por setor ou unidade sem se preocupar com custo por mensagem. Adicionar um novo setor é adicionar uma nova conexão e um novo token.
Para a entrada, envie uma mensagem de outro celular ao número de atendimento e confirme que o seu endpoint foi acionado com os dados certos. Para a saída, dispare a chamada de envio com um número de teste e verifique se a mensagem chegou e se a resposta da API trouxe success: true. Depois junte os dois: mande uma mensagem e veja a resposta automática chegar.
Validar nas duas direções leva poucos minutos:
Phone seu. Confira três coisas — a mensagem chegou no aparelho, a resposta veio com "success": true e existe um id em data. Se vier erro de autenticação, revise o header token; se vier erro de número, revise o formato (só dígitos, com DDI e DDD).Vale também simular o cenário de múltiplos números: se você separou por setor, mande mensagem para cada número e confirme que a resposta sai pelo token correto, sem cruzar setores.
O zapon não usa a API oficial da Meta: o número conectado é um WhatsApp comum, então a saúde dele depende de você. No atendimento isso costuma ser tranquilo, porque você responde a quem já falou com a empresa. Mantenha respostas relevantes, evite disparos em massa não solicitados e use números dedicados. O preço é R$ 27 por número, com mensagens ilimitadas.
Alguns pontos para o atendimento durar e funcionar bem:
id retornado e controle o que já foi respondido.token como senha. Guarde-os como variáveis de ambiente ou em um cofre de segredos, nunca escritos no código-fonte versionado.Em duas direções. Na entrada, cada mensagem do cliente chega ao seu sistema como um evento, entregue por webhook. Na saída, cada resposta sai por uma chamada POST à API. Esse ciclo de receber e responder é a base de todo o atendimento.
Cadastre uma URL pública do seu sistema na seção Webhook da conexão, no painel do zapon, e marque o evento de mensagem recebida. Cada mensagem que o cliente envia vira uma requisição POST no seu endpoint, com o remetente e o conteúdo.
A URL é https://api.zapon.dev/chat/send/text, método POST, com o header token e um body JSON contendo Phone (número do cliente, só dígitos, com DDI e DDD) e Body (o texto da resposta). A resposta da API traz success true e o id da mensagem.
Sim. Receba a mensagem pelo webhook, decida a resposta com a sua lógica (regras, menu ou uma IA) e responda com a chamada de envio. Ouvir, decidir e responder, repetido a cada mensagem, é todo o ciclo de um chatbot.
Sim. A API não limita atendentes: você modela a equipe e o roteamento dentro do seu sistema, decidindo quem responde cada conversa. Todos os atendentes podem usar o mesmo número, ou números diferentes por setor, conforme a necessidade.
Sim, conectando números diferentes — um por setor ou unidade. Cada número tem o seu próprio token e webhook, e você escolhe de qual número a resposta sai trocando o header token na chamada de envio.
Não. O zapon conecta um número de WhatsApp comum por QR Code ou código de pareamento. Não há fila de aprovação da Meta, templates obrigatórios nem custo por mensagem.
São R$ 27 por número por mês, com mensagens ilimitadas. Você ainda tem 14 dias grátis, sem cartão, para testar o atendimento pela API antes de assinar — e cada novo setor é apenas mais um número.
14 dias grátis, sem cartão. Crie a conta, leia o QR Code e responda seus clientes pela API.