O seu contas a receber já sabe quais títulos vencem na sexta e quais estão em atraso há doze dias. Com a API do zapon, esse mesmo dado dispara o aviso pelo WhatsApp com a linha digitável junto — e a resposta do cliente volta por webhook para o financeiro tratar acordo, segunda via e comprovante sem ninguém copiar nada de uma planilha.
Cobrança tem duas contas que ninguém coloca no papel. A primeira é o título que vence sem aviso: o cliente não é caloteiro, ele perdeu o boleto no meio de quarenta e-mails e só lembra quando alguém liga. A segunda é o tempo de quem cobra — o analista do financeiro que passa a manhã de segunda mandando segunda via um a um, no meio do fechamento.
As duas encolhem quando o aviso sai do sistema que já tem os títulos e chega num canal que a pessoa lê. É o que uma API de WhatsApp resolve: o zapon expõe uma API REST direta — header token, JSON de entrada e de saída — que o seu ERP, o seu financeiro caseiro ou a sua ferramenta de automação chama como chamaria qualquer serviço. Abaixo estão a régua completa, os endpoints em cURL e Node, o evento que chega quando o cliente responde e, principalmente, a regra que impede o pior erro dessa automação: cobrar quem já pagou.
Porque o único aviso costuma ser o e-mail com o boleto anexado, disparado no dia da emissão, semanas antes do vencimento. Ele chega, é arquivado e some. No dia do vencimento não existe nenhum lembrete — e o cliente descobre que atrasou quando o financeiro liga, já com juros no meio da conversa. Um aviso curto três dias antes, com a linha digitável e o PIX copia e cola na própria mensagem, elimina o atrito entre lembrar e pagar.
Vale separar dois clientes que o financeiro trata como um só:
Porque ela compete com propaganda no mesmo lugar. Cobrança por e-mail cai em promoções, vai para spam e não tem confirmação de leitura confiável. No WhatsApp a mensagem aparece na tela de bloqueio e a linha digitável dá para copiar com um toque. É o mesmo motivo pelo qual o canal funciona e pelo qual ele precisa ser usado com cuidado: ele interrompe a pessoa.
Porque o custo é fixo por título. Duzentos boletos vencendo no dia 10 são duzentas ações manuais, e o analista escolhe: ou cobra os grandes e deixa os pequenos, ou cobra todos e não faz a conciliação. Uma rotina que varre a carteira por faixa de dias em relação ao vencimento trata os duzentos com o mesmo esforço de tratar dez — e sobra tempo justamente para o que exige gente, que é negociar acordo.
Três peças: um número de WhatsApp que a empresa controla, uma conexão no zapon com esse número lido por QR Code ou código de pareamento, e um sistema que responda a uma pergunta simples — quais títulos vencem daqui a três dias, quais vencem hoje e quais estão em aberto e vencidos. Não é preciso servidor próprio, conta na Meta nem template aprovado.
token, que autentica todas as chamadas daquele número. Se a empresa cobra por CNPJ diferente, use uma conexão por CNPJ — o cliente reconhece quem está cobrando.Se o ERP roda código ou tem área de integrações, ele chama a API direto: uma rotina agendada consulta os títulos e faz um POST por cliente. Se ele é fechado, leia os dados por fora — relatório de contas a receber exportado, consulta no banco, arquivo de retorno já processado — e dispare dali com uma ferramenta de automação no meio. A API não precisa entender de título; ela precisa de telefone e texto.
Dá, e é o arranjo que dá menos problema. O cliente responde para o número que já está no cadastro dele, e o que a automação não resolve fica visível na conversa para o analista tratar. O contrário — abrir um número novo só para a régua — cria um número desconhecido que dispara cobrança e some quando alguém responde. Esse é o perfil que mais recebe denúncia.
Cinco etapas: (1) três dias antes do vencimento sai um lembrete de conveniência, com a segunda via e o PIX copia e cola; (2) no dia do vencimento sai um aviso curto com o meio de pagamento; (3) quando a baixa entra no financeiro, sai a confirmação de pagamento e o cliente sai de todas as demais filas; (4) se o título vence, uma régua de atraso espaçada oferece caminho — segunda via, falar com o financeiro, parcelamento — e termina depois de um número definido de tentativas; (5) se o cliente responde pedindo prazo, o webhook entrega a mensagem e o caso sai da régua automática e entra na fila de acordo.
Cada envio tem um objetivo próprio. Repetir o mesmo texto em cinco datas diferentes é o jeito mais rápido de ser bloqueado.
Um lembrete, não uma cobrança. Nessa data o cliente está em dia e a mensagem existe para poupar o trabalho dele de procurar o boleto: identificação da nota, data de vencimento e o meio de pagamento na própria mensagem — linha digitável, PIX copia e cola, ou os dois. Nada de falar em consequência: não há nada a cobrar de quem ainda não venceu. É também o envio que mais devolve resultado, porque atinge quem só precisava lembrar.
Curto, num horário em que ainda dá para pagar — meio da manhã funciona melhor que fim da tarde, porque compensação tem hora. Uma linha dizendo que o título vence hoje, o meio de pagamento e uma saída: se já pagou, avise por aqui. Essa saída não é gentileza, é operação: a resposta do cliente costuma chegar antes da baixa bancária e evita o envio seguinte.
Quando a baixa entra no financeiro, e não antes. A confirmação encerra o assunto do lado do cliente e evita a ligação para perguntar se o pagamento caiu. Mas o valor real desse passo é outro: é ele que tira o cliente da régua. Daí vem a regra de ouro de toda cobrança automatizada — a rotina lê o status do título no momento do envio, nunca uma lista montada ontem à noite. Cobrar quem já pagou é o pior erro possível aqui: o cliente que pagou em dia e recebeu uma cobrança no dia seguinte deixa de confiar no canal, e a partir daí ignora todos os avisos, inclusive os corretos.
Espaçada e finita. Um contato poucos dias depois do vencimento, outro na semana seguinte, um terceiro mais adiante — nunca dois no mesmo dia, nunca dia sim, dia não. Cada mensagem oferece caminho, não pressão: segunda via com nova data, falar com o financeiro, proposta de parcelamento. E a régua tem fim: depois de um número definido de tentativas sem resposta, o assunto deixa de ser mensagem automática e vira tarefa de uma pessoa. Régua sem fim vira perseguição, e perseguição vira denúncia do número.
Ele vai responder — "consigo pagar dia 20", "dá para dividir em três?". O webhook entrega essa mensagem ao seu sistema, que faz duas coisas na mesma transação: marca o título como em negociação, o que suspende os envios automáticos, e cria o caso na fila do financeiro com o telefone e o texto original. Proposta de acordo é decisão de gente. A automação garante que o pedido não se perca e que ninguém receba a próxima mensagem da régua enquanto negocia.
Quatro dão conta do fluxo inteiro: POST /chat/send/text para os avisos, POST /chat/send/buttons para a resposta em um toque, POST /chat/send/document para mandar boleto e segunda via em PDF e POST /user/check para saber se o telefone do cadastro tem WhatsApp antes do primeiro disparo. A base é https://api.zapon.dev e a autenticação é um header token. São 49 endpoints publicados — 23 de /chat, 18 de /group e 8 de /user —, mas o financeiro vive nesses quatro.
O header é literalmente token: não é Authorization, não é Bearer, não há OAuth. Ele vale como senha do número — quem o tem cobra em nome da empresa, então guarde-o como variável de ambiente e nunca no código do ERP.
Um POST em /chat/send/text com dois campos obrigatórios: Phone, em formato internacional só com dígitos, e Body, o texto. O código do PIX vai numa linha isolada, para o cliente conseguir copiar sem arrastar junto o resto da frase.
curl -X POST https://api.zapon.dev/chat/send/text \ -H "token: SEU_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "Phone": "5511999999999", "Body": "Olá, Marcelo. Aqui é do financeiro da Metalúrgica Exemplo.\n\nA nota de serviço 4471 vence em 12/03 (quinta).\n\nPIX copia e cola:\n00020126580014BR.GOV.BCB.PIX0136c1f3a9e2-4b77-4f10-9d2c-8ab5520400005303986540199.905802BR\n\nSe preferir boleto, respondo com a segunda via por aqui." }'
A resposta traz o identificador da mensagem no WhatsApp:
{
"code": 200,
"success": true,
"data": {
"Details": "Sent",
"Id": "90B2F8B13FAC8A9CF6B06E99C7834DC5",
"Timestamp": "2026-03-01T09:12:08-03:00"
}
}Grave esse Id na movimentação do título. Ele é a prova de que aquele aviso saiu, com data e hora, e é o que impede a rotina de mandar o mesmo lembrete duas vezes se ela rodar de novo.
Uma rotina diária calcula, para cada título em aberto, quantos dias faltam para o vencimento ou quantos dias já se passaram, e escolhe a mensagem pela faixa. O trecho que decide a qualidade da régua é a releitura do status imediatamente antes de cada envio.
// regua.js — roda todo dia útil às 9h30 const API = "https://api.zapon.dev"; const TOKEN = process.env.ZAPON_TOKEN; async function enviarTexto(phone, body) { const r = await fetch(`${API}/chat/send/text`, { method: "POST", headers: { "token": TOKEN, "Content-Type": "application/json" }, body: JSON.stringify({ Phone: phone, Body: body }) }); const json = await r.json(); if (!r.ok || !json.success) throw new Error(json.error || `HTTP ${r.status}`); return json.data.Id; } const faixa = (d) => d === 3 ? "pre_vencimento" : d === 0 ? "vence_hoje" : d === -3 ? "atraso_1" : d === -10 ? "atraso_2" : d === -21 ? "atraso_3" : null; // depois disso, ninguém mais dispara const pausa = (ms) => new Promise((r) => setTimeout(r, ms)); for (const t of await titulosEmAberto()) { const etapa = faixa(diasAteVencimento(t)); if (!etapa) continue; if (t.cliente.optOut || t.cliente.canalAlternativo) continue; if (await jaEnviado(t.id, etapa)) continue; // nunca duas vezes a mesma etapa const atual = await lerTitulo(t.id); // releitura no instante do envio if (atual.status !== "aberto") continue; // pago, baixado ou em negociação: fora try { const id = await enviarTexto(atual.cliente.telefone, textoDaEtapa(etapa, atual)); await registrarEnvio(atual.id, etapa, id); } catch (e) { await registrarFalha(atual.id, etapa, String(e)); // vira tarefa do analista } await pausa(4000); // a carteira inteira no mesmo segundo não parece gente }
Repare no que esse laço protege. A faixa fecha a régua depois da terceira tentativa. O optOut respeita quem pediu para não receber e o canalAlternativo respeita quem pediu para ser cobrado por outro meio. O jaEnviado impede repetição da mesma etapa. E a releitura do título separa a régua que serve da régua que constrange: entre a montagem da lista e o envio pode ter caído um PIX.
O endpoint /chat/send/buttons envia botões de resposta rápida, com rótulo curto — o WhatsApp corta o que passar de vinte caracteres. Cada botão carrega um id definido por você, que volta no webhook; embuta o número do título nele para a resposta chegar amarrada ao registro certo, sem depender de interpretar texto. Além da resposta rápida, o mesmo endpoint monta botão que abre um link ("type": "cta_url"), botão que abre o discador ("type": "cta_call") e botão que copia um código ("type": "copy") — e os tipos convivem na mesma mensagem. O toque em resposta rápida volta no webhook; os outros três agem no aparelho de quem recebe.
POST https://api.zapon.dev/chat/send/buttons token: SEU_TOKEN { "Phone": "5511999999999", "Body": "Marcelo, a nota 4471 consta em aberto por aqui. Como prefere resolver?", "Footer": "Financeiro — Metalúrgica Exemplo", "Buttons": [ { "id": "tit4471|segundavia", "text": "Segunda via" }, { "id": "tit4471|pago", "text": "Já paguei" }, { "id": "tit4471|falar", "text": "Falar com vocês" } ] }
Os três rótulos cobrem as três realidades do atraso: quem perdeu o boleto, quem já pagou e quem precisa negociar. Note que nenhum deles é "pagar agora" — o botão não deve empurrar, deve abrir caminho.
Pelo /chat/send/document. O arquivo vai como data URI em base64, com FileName e um Caption opcional. Use um nome de arquivo que o cliente entenda ao ver na lista de mídias — boleto-4471.pdf diz mais do que uma sequência de números do sistema.
curl -X POST https://api.zapon.dev/chat/send/document \ -H "token: SEU_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "Phone": "5511999999999", "Document": "data:application/pdf;base64,JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGg…", "FileName": "boleto-4471.pdf", "Caption": "Segunda via da nota 4471, com vencimento para 20/03. A linha digitável está na primeira página." }'
Antes do primeiro disparo em cima de uma carteira antiga, vale limpar a base com POST /user/check: ele recebe uma lista de telefones e devolve quais têm conta no WhatsApp, o que evita gastar a régua em número de telefone fixo herdado de cadastro antigo. Fora esses quatro endpoints, o financeiro raramente precisa de mais — imagem, para um comprovante de repasse, e localização, quando a cobrança é presencial, são as exceções úteis entre as 13 formas de envio disponíveis.
Cada conexão tem o seu webhook: você cadastra no painel a URL do seu sistema e escolhe os eventos. A partir daí, toda mensagem que chega naquele número é entregue como um POST nessa URL, com o conteúdo inteiro — telefone, identificador, horário, texto e, quando é resposta de botão, o id que você definiu. Não existe polling; a mensagem vem até você, e o que ela vira — baixa, caso de acordo, tarefa do analista — é decisão do seu código.
O ciclo tem três partes separadas: o webhook entrega o evento, a sua regra interpreta e a ação acontece no seu sistema. A API não sabe o que é um título; ela sabe que uma mensagem chegou.
O corpo traz o tipo do evento e a mensagem completa. Assim chega quem respondeu por escrito:
{
"type": "Message",
"event": {
"Info": {
"ID": "3EB0C767D26A1B5F7C83",
"Chat": "[email protected]",
"Sender": "[email protected]",
"IsFromMe": false, "IsGroup": false,
"PushName": "Marcelo Prado",
"Timestamp": "2026-03-11T18:04:22-03:00"
},
"Message": { "conversation": "paguei ontem, consigo dividir o restante?" }
}
}
// tocando num botão, muda só o bloco Message:
"Message": { "buttonsResponseMessage": {
"selectedButtonID": "tit4471|pago",
"Response": { "SelectedDisplayText": "Já paguei" }
} }
// mandando o comprovante em PDF, o bloco vira:
"Message": { "documentMessage": {
"fileName": "comprovante.pdf",
"mimetype": "application/pdf",
"caption": "segue"
} }Dois detalhes economizam horas de depuração. O corpo pode chegar como JSON puro ou como formulário codificado, com o JSON dentro de um campo — aceite os dois. E o que o próprio número envia também gera evento, com IsFromMe igual a true: ignore, ou o analista respondendo um cliente vai acionar a sua própria automação.
Suspendendo primeiro e conferindo depois. Quando o cliente diz que pagou, o sistema marca o título como pagamento informado — estado que interrompe a régua — e cria a tarefa de conciliação. Se a baixa aparecer, o título fecha; se não aparecer em alguns dias, quem retoma é uma pessoa, com o histórico na mão. O mesmo vale para o pedido de acordo: sai da régua, entra na fila.
app.post("/financeiro/whatsapp", express.json(), async (req, res) => { res.sendStatus(200); // responda primeiro, processe depois const ev = req.body?.event ?? req.body, info = ev?.Info ?? {}; if (info.IsFromMe || info.IsGroup) return; // nada de cobrança em grupo if (await jaProcessado(info.ID)) return; // o mesmo evento pode chegar 2x const telefone = String(info.Chat || "").split("@")[0]; const botao = ev?.Message?.buttonsResponseMessage?.selectedButtonID ?? ""; const doc = ev?.Message?.documentMessage; const texto = (ev?.Message?.conversation ?? ev?.Message?.extendedTextMessage?.text ?? "").trim().toLowerCase(); const tit = botao ? await buscarTitulo(botao.split("|")[0]) : await tituloEmAbertoDoTelefone(telefone); if (!tit) return filaDoFinanceiro(telefone, texto); if (doc) { // comprovante anexado await marcarStatus(tit.id, "pagamento_informado"); await filaDeConciliacao(tit.id, doc.fileName); return enviarTexto(telefone, "Recebi o comprovante. Vou conferir a baixa e te confirmo."); } const acao = botao ? botao.split("|")[1] : /pagu?ei|paguei|quitei/.test(texto) ? "pago" : /parcel|dividir|prazo|acordo/.test(texto) ? "acordo" : /segunda via|boleto|linha digit/.test(texto) ? "segundavia" : null; if (acao === "pago") { await marcarStatus(tit.id, "pagamento_informado"); // para a régua na hora await filaDeConciliacao(tit.id, null); return enviarTexto(telefone, "Obrigado pelo aviso. Suspendi os lembretes e vou conferir a baixa."); } if (acao === "acordo") { await marcarStatus(tit.id, "em_negociacao"); // sai da régua automática await filaDeAcordo(tit.id, texto); return enviarTexto(telefone, "Certo. O financeiro vai te chamar por aqui para combinar."); } if (acao === "segundavia") return enviarSegundaVia(tit); return filaDoFinanceiro(telefone, texto); // o resto é conversa de gente });
Ele vai contestar valor, dizer que o serviço não foi entregue, pedir nota de serviço corrigida, avisar que quem paga é o escritório de contabilidade. Nada disso se resolve com regra automática, e tentar responder tudo por robô piora a situação. Deixe a mensagem visível na conversa e crie uma pendência — a conversa já está no WhatsApp da empresa, e o analista responde no próprio aplicativo. O papel da automação aqui é sinalizar que aquele cliente está esperando e, principalmente, garantir que a régua pare enquanto isso.
Cliente com contrato vigente e fatura em aberto é comunicação esperada: ele forneceu o telefone para tratar da relação comercial e o assunto é o que ele contratou. Carteira comprada de terceiro, dívida cedida e cobrança em nome de outra empresa são outra história — ali o cliente não escolheu falar com você, e o cuidado precisa ser redobrado. E cobrança nunca vira porta de entrada para oferta: misturar a régua com promoção é o caminho mais curto para o número ser denunciado.
optOut e canalAlternativo fizeram no exemplo) e ofereça o outro meio: e-mail, correspondência, contato do analista.Escrevendo como quem avisa, não como quem pressiona. Frase curta, letra normal, identificação clara de quem está falando, o dado objetivo do título e um caminho para resolver. Sem maiúsculas gritando, sem contagem regressiva, sem insinuar consequência, sem adjetivo sobre o cliente. A régua não precisa assustar para funcionar: o cliente que pode pagar paga com um lembrete educado, e o que não pode não paga nem sob pressão — só deixa de responder.
Existe uma lista curta do que nunca entra numa mensagem automática de cobrança:
IsGroup. A conversa é com quem deve, e com mais ninguém.A diferença entre uma régua que sustenta a relação comercial e uma que queima o número costuma caber em três linhas de texto:
// ruim: maiúscula gritando, valor exposto, tom de acusação, urgência artificial "SR. MARCELO, CONSTA DÉBITO EM ABERTO DE R$ 1.480,00 VENCIDO HÁ 12 DIAS. REGULARIZE HOJE PARA EVITAR TRANSTORNOS. AGUARDAMOS." // bom: identifica quem fala, cita o título, não expõe valor, abre caminho "Olá, Marcelo. Aqui é a Ana, do financeiro da Metalúrgica Exemplo. A nota 4471 consta em aberto por aqui. Se você já pagou, me avisa que eu confiro a baixa. Se preferir, mando a segunda via com nova data ou a gente combina uma forma de acertar. Bom dia!"
O texto bom é mais longo e mais lento, e é isso mesmo. Ele assume que pode haver um erro do lado de quem cobra — a baixa que não entrou, o pagamento feito ontem — e por isso não humilha ninguém à toa. Também é o único dos dois que dá ao cliente uma resposta possível: o primeiro só admite pagar ou ficar calado.
R$ 27 por mês por número conectado, sem cobrança por mensagem: o custo não muda se o financeiro disparar 80 avisos ou 5.000. A cota é de 300 mensagens por dia por número, o que acomoda a régua de uma carteira inteira e evita a rajada que faz o WhatsApp bloquear o número do financeiro. O teste é de 14 dias sem cartão e a contagem só começa na primeira conexão — dá para criar a conta, integrar o ERP com calma e conectar o número só quando a régua estiver pronta.
Em cobrança essa previsibilidade pesa mais do que em qualquer outro uso, porque a régua é naturalmente repetitiva: são até cinco toques por título, mais confirmação e segunda via. Com preço por mensagem, alguém do financeiro acabaria cortando justamente o aviso de pré-vencimento — o mais barato de todos em esforço e o que evita o atraso antes de ele existir.
O painel mostra o estado de cada conexão e atualiza a cada 10 segundos enquanto a página está aberta. Para não depender de alguém olhando a tela no dia 10, assine os eventos de conexão no webhook: Disconnected avisa a queda e LoggedOut avisa que o número precisa ler o QR Code de novo. E trate a lista de falhas de envio como uma tarefa diária do financeiro — foi o papel do registrarFalha no exemplo. Aviso que não saiu vira atraso que ninguém explica.
Dá, sempre que o ERP permitir consultar os títulos por HTTP, por banco ou por exportação. O ponto crítico não é a integração de saída, é a frequência com que a baixa entra: se a conciliação bancária roda uma vez por dia, a régua precisa rodar depois dela, nunca antes. Quando o intervalo é grande, use o "já paguei" respondido pelo cliente como trava provisória até a baixa aparecer.
Com três travas somadas. A rotina relê o status do título imediatamente antes de cada envio, e não confia na lista montada antes. Qualquer aviso de pagamento vindo do cliente muda o status para "pagamento informado" e interrompe a régua na hora. E cada etapa fica registrada com o Id da mensagem, para que rodar a rotina duas vezes não gere dois envios.
Dá, e costuma valer a pena: o PIX copia e cola no corpo do texto, em linha isolada para poder ser copiado com um toque, e o boleto em PDF logo em seguida por POST /chat/send/document. Evite só empilhar três formas de pagamento na mesma mensagem — duas opções ajudam, cinco fazem a pessoa adiar a decisão.
Marca o título como em negociação, o que suspende todos os envios automáticos daquele registro, e cria o caso na fila do financeiro com o telefone e o texto original. Proposta de acordo é decisão humana e não deve ser negociada por regra automática. A automação garante duas coisas: que o pedido não se perca e que ninguém receba a próxima mensagem da régua enquanto negocia.
Em quatro situações: quando o título é pago ou baixado, quando o cliente informa pagamento, quando entra em negociação e quando ele pede para não receber mais por esse canal. Fora isso, existe um fim por contagem: depois de um número definido de tentativas sem resposta, o caso deixa de ser mensagem automática e vira tarefa de uma pessoa. Régua que nunca termina é régua que gera denúncia.
R$ 27 por mês por número conectado, sem cobrança por mensagem, com teto de 300 mensagens por dia em cada número. É espaço de sobra para a régua de vencimento de uma carteira inteira e um limite que protege o número da cobrança do bloqueio por volume. O teste é de 14 dias sem cartão e só começa a contar quando você conecta o primeiro número. Se a empresa cobra por mais de um CNPJ, é uma conexão por número.
Pode, e em cobrança esse risco é maior do que em qualquer outro uso, porque a mensagem é indesejada por natureza. O risco existe em qualquer API, inclusive na oficial da Meta, e não é eliminável — é gerenciável: fale só com quem tem relação contratual viva, mantenha tom de aviso, respeite horário comercial, limite as tentativas, pare quando pedirem e responda quem responde. Denúncia e bloqueio de muitos destinatários é o que derruba um número.
Dá, e é o arranjo mais seguro. O cliente reconhece o número que já está no cadastro dele e responde ali; o analista continua atendendo no aparelho. Número novo criado só para disparar cobrança é exatamente o perfil que mais recebe denúncia, porque para o destinatário ele é um desconhecido falando de dinheiro.
14 dias grátis, sem cartão — a contagem só começa quando você conectar o número. Crie a conta, ligue o contas a receber na API e dispare o primeiro aviso de pré-vencimento.