Quem compra o arranjo não está no endereço da entrega e passa o dia sem saber se deu certo. Com a API do zapon, o seu sistema de pedidos avisa o remetente em cada etapa — dados conferidos, arranjo aprovado, saiu para entrega, entregue com foto — e recebe por webhook a resposta dele quando algo precisa de decisão.
Floricultura não vende um produto que o cliente leva embora. Vende uma cena que vai acontecer em outro endereço, num horário combinado, para uma pessoa que não comprou nada. Entre a compra e essa cena existem horas de silêncio, e é nesse silêncio que nasce quase todo o pós-venda do setor.
O canal já existe: o pedido foi fechado no WhatsApp e é lá que o cliente espera notícia. Falta o aviso sair sozinho, disparado pelo sistema que já sabe qual entrega está na rota. É o que uma API de WhatsApp faz. O zapon expõe uma API REST direta — header token, JSON entrando e saindo — que o seu sistema de pedidos ou o seu fluxo de automação chama por HTTP. Abaixo, o fluxo completo, os endpoints em cURL e Node, o evento que chega quando o remetente responde e a regra que define esta vertical: com quem a automação pode falar.
Porque quem paga não vê o que aconteceu. O arranjo tem que chegar antes do jantar de aniversário, no escritório antes das 17h, no velório na hora certa — e o remetente carrega essa cena o dia inteiro sem confirmação nenhuma. A ansiedade vira ligação, e a ligação chega justamente no dia em que a loja tem cem entregas na rua.
São três perguntas que se repetem em toda ligação:
Porque só aparece quando o entregador já está na porta, com a rota fechada. Endereço sem número do apartamento, rua homônima em outro bairro, empresa que mudou de andar. Quando a tentativa falha, a flor volta para a loja e não pode ser reentregue no dia seguinte com a mesma qualidade: perde-se o produto, a rota e a data — que era o motivo inteiro da compra. Uma conferência por escrito na véspera custa uma mensagem.
Porque o volume de um mês cabe em um dia. Cada entrega em rota é um remetente ansioso, e todos ligam na mesma faixa de horário. Quem atende é a mesma pessoa que deveria estar conferindo endereço e fechando embalagem.
Três coisas: um número de WhatsApp da loja, uma conta no zapon com esse número conectado por QR Code ou código de pareamento, e um lugar onde os pedidos do dia tenham telefone do remetente, data e status. Não é preciso servidor próprio, conta na Meta, aprovação de template nem aplicativo instalado no celular de ninguém.
token, credencial de todas as chamadas daquele número.Dá. Muita loja organiza o dia numa planilha com destinatário, endereço, faixa de horário e telefone de quem comprou. Se cada linha tem um status que alguém atualiza, esse status já é gatilho: a automação lê a mudança e chama a API. O que a API precisa saber é sempre o mesmo — telefone e texto.
Seis etapas: (1) o pedido fecha e os dados da entrega voltam por escrito para o remetente conferir; (2) a foto do arranjo montado vai para ele aprovar; (3) na véspera, confirmam-se data, faixa de horário e endereço; (4) na saída, o aviso vai para o remetente — nunca para o destinatário; (5) entregue, ele recebe o nome de quem recebeu e a foto; (6) se a entrega falha, ele decide a nova tentativa por botões.
Cada passo tem objetivo próprio. Repetir o mesmo texto seis vezes é o jeito mais rápido de o cliente parar de ler.
É o passo mais crítico e o mais ignorado. A conversa da venda vem picada: o endereço num áudio, a data em outra mensagem, o cartão ditado no meio. O que fecha o pedido é devolver tudo organizado numa mensagem só — destinatário, endereço com número, complemento e ponto de referência, data, faixa de horário e o texto do cartão exatamente como será escrito. O remetente aprova antes de a produção começar.
Com a foto do arranjo montado. A loja vende de catálogo, mas monta com o que chegou no mercado naquela manhã, e o cliente comprou uma imagem. A foto do que foi produzido encerra a discussão antes de o entregador sair. Substituição de flor ou de cor por sazonalidade precisa de aval, não de improviso: mande a foto, explique a troca e espere a resposta.
Data, faixa de horário e endereço, nessa ordem. É a última janela barata para corrigir um endereço incompleto: hoje custa uma mensagem, amanhã custa o arranjo. Peça a confirmação do número e do complemento e pergunte se há alguém no local naquela faixa. Pedido feito com três semanas de antecedência muda de contexto — gente muda de endereço, festa muda de local.
O remetente. Sempre. É aqui que a automação copiada de loja virtual erra: manda "seu pedido saiu para entrega" para o destinatário e destrói a surpresa, que era o produto. O aviso é para quem pagou, com a faixa de horário prevista. Se o pedido tem observação de "entregar quando ela estiver em casa", este é o momento de o cliente avisar que mudou.
Com dois dados: o nome de quem recebeu — o destinatário, o porteiro, a recepção — e a foto do arranjo entregue. É o passo que encerra a ansiedade do dia e o chamado de pós-venda, e separa "entregamos" de "entregue às 15h20, recebido por Marta, na portaria do bloco B".
Ninguém no endereço, destinatário ausente, portaria que não recebe, endereço inexistente. A entrega frustrada tem mensagem própria, escrita sem culpar ninguém: o que houve, onde o arranjo está agora e quais são as opções. A decisão volta em botões — tentar hoje, outro dia, outro endereço — com o número do pedido dentro do id. Enquanto ele não decide, o arranjo fica em condicionamento na loja, e ele precisa saber disso.
Quatro: POST /chat/send/text para os avisos, POST /chat/send/image para a foto do arranjo e a da entrega, POST /chat/send/buttons para as decisões do remetente e POST /user/check para conferir se o telefone do pedido tem WhatsApp. Todos na base https://api.zapon.dev, com o header token — não é Authorization, não é Bearer, não há OAuth. São 49 endpoints publicados, mas a operação de entrega vive nesses quatro.
Um POST em /chat/send/text com Phone, o número em formato internacional só com dígitos, e Body, o texto.
curl -X POST https://api.zapon.dev/chat/send/text \ -H "token: SEU_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "Phone": "5511999999999", "Body": "Pedido 7712 confirmado. Confira antes de montarmos:\n\nArranjo: buquê de 12 rosas vermelhas\nPara: Marta Ribeiro\nEndereço: Rua das Acácias, 120, ap. 74, bloco B — portaria 24h\nReferência: em frente à padaria\nData: 09/05 (sábado)\nHorário: entre 9h e 12h\n\nCartão (escrito à mão, exatamente assim):\n\"Mãe, obrigado por tudo. Com amor, Júlio e Bia.\"\n\nEstá tudo certo? Responda CONFIRMO ou diga o que devo corrigir." }'
A resposta traz o identificador da mensagem no WhatsApp. Guarde esse Id junto do pedido: ele prova qual aviso saiu, em qual etapa, e impede reenvio se a rotina rodar duas vezes.
{
"code": 200,
"success": true,
"data": {
"Details": "Sent",
"Id": "90B2F8B13FAC8A9CF6B06E99C7834DC5",
"Timestamp": "2026-03-01T09:12:08-03:00"
}
}Em dia comum o gatilho é a mudança de status: o entregador sai, o pedido vira em rota, o aviso sai. Em data de pico, cinquenta pedidos mudam de status na mesma conferência de saída — e aí é preciso uma fila com pausa entre os envios.
// saiu-para-entrega.js — roda quando a rota do dia é fechada 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 pausa = (ms) => new Promise((r) => setTimeout(r, ms)); for (const p of await pedidosEmRota()) { if (p.status !== "em_rota" || p.avisos.saida || p.remetente.optOut) continue; try { const id = await enviarTexto(p.remetente.telefone, // nunca p.destinatario `${p.remetente.nome}, o pedido ${p.numero} saiu para entrega.\n\n` + `Previsão: entre ${p.janelaInicio} e ${p.janelaFim}.\n` + `Quando for entregue, mando o nome de quem recebeu e a foto.`); await registrarAviso(p.id, "saida", id); // guarda o Id: evita duplicar } catch (e) { await registrarFalha(p.id, "saida", String(e)); // vira tarefa do balcão } await pausa(4000); // cem avisos no mesmo minuto não parecem humanos }
Três linhas sustentam o laço em dia cheio. O continue impede aviso repetido e envio a quem pediu para sair. O registrarAviso guarda o Id. E o comentário ao lado do telefone existe porque este é o campo que alguém troca por engano um dia — e trocar o remetente pelo destinatário estraga a surpresa de quem pagou por ela.
O /chat/send/buttons envia botões de rótulo curto. Cada um carrega um id definido por você, e é ele que volta no webhook: coloque o número do pedido aí dentro e a decisão chega amarrada ao registro certo, sem interpretar texto livre. 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": "Pedido 7712: a rosa vermelha que você escolheu não chegou hoje no mercado. Posso montar com uma importada na mesma tonalidade, sem mudar o valor. Como prefere?", "Footer": "Floricultura Exemplo", "Buttons": [ { "id": "ped7712|trocar", "text": "Pode trocar" }, { "id": "ped7712|remarcar", "text": "Entregar amanhã" }, { "id": "ped7712|falar", "text": "Falar com a loja" } ] }
Os mesmos três botões resolvem a entrega frustrada do passo 6, trocando o texto e os identificadores: ped7712|tentar_hoje, ped7712|outro_dia, ped7712|outro_endereco. A explicação inteira vai no Body, nunca no rótulo. Se as opções passarem de três, como faixas de horário de reentrega, o envio em lista dá conta de um menu maior.
Pelo mesmo endpoint, POST /chat/send/image, com Phone, Image — o arquivo em data URI base64 ou uma URL — e Caption. As duas fotos do fluxo têm finalidades opostas, e o que muda é a legenda. A do passo 2 pede alguma coisa: mostra o arranjo montado e espera aprovação. A do passo 5 não pede nada: é prova, chega junto do nome de quem recebeu e fecha o pedido.
curl -X POST https://api.zapon.dev/chat/send/image \ -H "token: SEU_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "Phone": "5511999999999", "Image": "data:image/jpeg;base64,/9j/4AAQSkZJRg…", "Caption": "Pedido 7712 entregue às 15h20. Recebido por Marta Ribeiro, na portaria do bloco B." }'
A foto de aprovação é a mesma chamada com outra legenda: "Pedido 7712 montado. Confere se está como você imaginou — ajusto até as 14h." Se a produção fotografa em resolução alta, redimensione antes de converter para base64.
Pedido anotado no balcão em dia cheio vem com dígito faltando, telefone fixo e número antigo. O POST /user/check recebe uma lista e diz quais têm conta — rode no fechamento do pedido, não na hora do aviso.
curl -X POST https://api.zapon.dev/user/check \ -H "token: SEU_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "Phone": ["5511999999999", "5511888888888"] }' // resposta { "code": 200, "success": true, "data": { "Users": [ { "Query": "5511999999999", "IsInWhatsapp": true, "JID": "[email protected]" }, { "Query": "5511888888888", "IsInWhatsapp": false, "JID": "" } ] } }
São 13 formas de envio ao todo, mais reação, "digitando", marcar como lido e histórico. Fora do que já foi mostrado, o útil aqui é o documento: o cliente corporativo que manda quarenta cestas no fim do ano não quer quarenta mensagens, quer um PDF com destinatário, horário e quem recebeu em cada linha.
Cada conexão tem um webhook próprio: você cadastra no painel a URL do seu sistema e escolhe os eventos. A partir daí, toda mensagem que chega no número da loja é entregue como um POST nessa URL, com o conteúdo inteiro no corpo — telefone, identificador, horário, texto e, quando é resposta de botão, o id que você definiu. Não há fila para consultar nem tela para ficar olhando.
O ciclo tem três partes que não se misturam: o webhook entrega, a sua regra interpreta e a ação acontece no seu sistema. A API não sabe o que é um arranjo; sabe que uma mensagem chegou.
O corpo traz o tipo do evento e a mensagem completa:
{
"type": "Message",
"event": {
"Info": {
"ID": "3EB0C767D26A1B5F7C83",
"Chat": "[email protected]",
"Sender": "[email protected]",
"IsFromMe": false, "IsGroup": false,
"PushName": "Júlio Ribeiro",
"Timestamp": "2026-03-11T18:04:22-03:00"
},
"Message": { "conversation": "confirmo" }
}
}
// quando ele toca num botão, muda só o bloco Message:
"Message": { "buttonsResponseMessage": {
"selectedButtonID": "ped7712|trocar",
"Response": { "SelectedDisplayText": "Pode trocar" }
} }Duas observações que economizam horas: 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 da loja envia também gera evento, com IsFromMe igual a true: ignore, ou a vendedora respondendo um cliente dispara a sua automação.
Responda 200 primeiro, descarte o que não interessa, identifique o pedido pelo id do botão, aplique a decisão e confirme por escrito o que foi feito — é isso que evita o "respondi e não sei se chegou", que traz o cliente de volta ao telefone.
app.post("/whatsapp/eventos", 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; // o que a loja enviou, e grupos, fora 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 texto = (ev?.Message?.conversation ?? ev?.Message?.extendedTextMessage?.text ?? "").trim().toLowerCase(); const ped = botao ? await buscarPedido(botao.split("|")[0]) : await pedidoAbertoPorTelefone(telefone); if (!ped) return filaDoBalcao(telefone, texto); const acao = botao ? botao.split("|")[1] : /^(confirmo|confirmado|ok|isso)$/.test(texto) ? "confirmar_dados" : null; if (acao === "confirmar_dados") { await liberarProducao(ped.id); return enviarTexto(telefone, `Dados confirmados. O ${ped.numero} entra na produção.`); } if (acao === "trocar") { await registrarSubstituicao(ped.id); return enviarTexto(telefone, "Combinado. Mando a foto do arranjo antes de sair."); } if (acao === "tentar_hoje" || acao === "outro_dia") { await reagendarEntrega(ped.id, acao); return enviarTexto(telefone, "Nova tentativa registrada. Aviso quando sair."); } return filaDoBalcao(telefone, texto); // endereço novo é assunto de gente });
Ele escreve, e quase sempre é o caso mais delicado do dia: "muda o endereço, ela está no trabalho", "o velório é na capela 3", "dá para trocar o cartão?". Isso não se resolve com regra automática. O que a automação não reconhece vira pendência para alguém tratar, e a conversa já está no WhatsApp da loja. Mudança de endereço, de data e de texto do cartão são decisões com custo — precisam de gente lendo.
Por padrão, não. Numa entrega de presente há duas pessoas com papéis diferentes: o remetente é o cliente, deu o telefone dele e espera notícia; o destinatário não comprou nada, não pediu mensagem nenhuma e muitas vezes não pode nem saber que o presente existe. Falar com ele por iniciativa da loja estraga o produto e é contato não solicitado. Só com autorização explícita do remetente, para um fim operacional, e nunca para vender depois.
Isso é regra no sistema, não recomendação:
Salvar o telefone do destinatário numa lista de marketing é o erro clássico desta vertical. A tentação é evidente: são pessoas com endereço conhecido, data conhecida e alguém que gosta delas o bastante para mandar flores. Mas é um telefone que chegou à loja por um terceiro, para uma finalidade única, sem consentimento de quem é dono dele. Usar essa lista em campanha é o caminho mais curto para o número da loja ser denunciado por gente que nunca comprou ali — e, pela LGPD, é uso fora da finalidade que justificou a coleta.
Com faixa, não com hora cravada. "Entre 9h e 12h" é uma promessa que a rota sustenta; "até as 12h" no Dia das Mães é uma promessa que o trânsito derruba, e cada minuto depois do combinado vira mensagem cobrando. Escreva a faixa na conferência, repita na véspera, avise na saída — e quando a agenda lotar, feche a agenda em vez de aceitar mais um pedido que a rota não comporta.
A data não é negociável, e é isso que separa esta vertical de qualquer outra entrega: aniversário, casamento e velório acontecem uma vez. Flor que chega no dia seguinte não é entrega atrasada, é entrega perdida. Em datas de pico, a loja faz num dia o volume de um mês — e a comunicação precisa acompanhar sem virar rajada: espace os envios e não dispare cem avisos no mesmo minuto.
O cartão é escrito à mão por quem entrega e ditado pelo cliente, muitas vezes em áudio, no meio de outros assuntos. Transcreva e devolva por escrito, com acento e pontuação, exatamente como será escrito, e peça a confirmação antes de escrever. Confira nomes e apelidos: "Vó Cida" e "Vó Zica" são cartões diferentes, e um deles é um problema. Cartão com nome errado não tem conserto — o arranjo já está na casa da pessoa.
Acontece toda semana, e mais ainda na véspera de data comemorativa: a cor pedida pode não existir naquele dia, ou o talo não ter a qualidade que a loja aceita mandar. A saída não é substituir em silêncio — a foto do arranjo mostra tudo. Avise antes de montar, com botões, e deixe a decisão com quem pagou. Substituição avisada é atendimento; substituição descoberta na foto é reclamação.
Fotografe o arranjo, não a pessoa. A prova precisa mostrar o produto entregue e, no máximo, o contexto do local — a mesa da recepção, o balcão da portaria. Rosto de quem recebeu, interior da casa e fachada com número visível não deveriam entrar no enquadramento. O nome de quem recebeu, digitado pelo entregador, faz esse trabalho com muito menos exposição.
Mensagem sobre um pedido que a pessoa fez é esperada: ela deu o telefone para isso. Campanha de data comemorativa para a base inteira é outra coisa — exige consentimento e um caminho fácil de sair. E há um terceiro grupo que não é base coisa nenhuma: os destinatários. Misturar aviso de entrega com disparo comercial no mesmo número é o que transforma o WhatsApp da loja num número denunciado às vésperas da data mais importante do ano.
optOut do exemplo em Node fez. O pedido chega em qualquer palavra, então alguém precisa olhar a fila de exceções todo dia.R$ 27 por mês por número conectado, sem cobrança por mensagem: o valor é o mesmo em fevereiro e em maio, com dez ou com quinhentas entregas na semana. Cada número tem cota de 300 mensagens por dia — cerca de 9.000 por mês —, folga suficiente para a semana do Dia das Mães e trava suficiente para o WhatsApp não bloquear o número. O teste é de 14 dias sem cartão e a contagem só começa na primeira conexão — dá para montar a integração com calma e conectar o número depois.
É essa previsibilidade que torna viável um fluxo de seis avisos por pedido. Com cobrança por mensagem, a conta de uma data de pico cresce junto com o volume e alguém acaba cortando justamente a mensagem que mais vale: a prova de entrega.
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 olhar a tela no meio da correria, assine os eventos de conexão no webhook: Disconnected avisa a queda e LoggedOut avisa que o número precisa reler o QR Code. E toda falha de envio deve cair numa lista visível — foi o que o registrarFalha fez —, olhada todo dia. Prova de entrega que não saiu precisa virar tarefa, não silêncio.
Quando o entregador dá baixa no pedido, o seu sistema chama a API e manda uma mensagem ao remetente com três informações: que foi entregue, o horário e o nome de quem recebeu — o destinatário, o porteiro ou a recepção. É a mensagem que encerra o principal motivo de ligação de pós-venda.
Dá. A API envia imagem, e ela aparece duas vezes no fluxo com finalidades diferentes: antes da rota, a foto do arranjo montado serve para o cliente aprovar e corrigir; depois, a foto do arranjo entregue serve como prova. Fotografe o produto e o contexto do local, não o rosto de quem recebeu.
Por padrão a automação fala só com o remetente, que comprou e deu o telefone. O destinatário não pediu mensagem nenhuma, e o aviso antecipado destrói a surpresa. Falar com ele só com autorização explícita do remetente, registrada no pedido, e apenas para combinar a entrega quando o endereço é incerto — nunca para oferecer nada.
A entrega frustrada vira uma mensagem própria para o remetente, dizendo o que houve, onde o arranjo está e quais são as opções, com botões para ele decidir entre tentar hoje, outro dia ou outro endereço. A resposta chega ao seu sistema pelo webhook com o número do pedido dentro do identificador do botão.
Os avisos saem por uma fila com pausa entre os envios, não todos no mesmo instante: cem mensagens no mesmo minuto não parecem comportamento humano e aumentam o risco para o número. Trabalhe com faixa de horário em vez de hora cravada e feche a agenda quando a rota lotar.
Não. É um telefone que chegou à loja por um terceiro, para uma finalidade única, sem consentimento do dono. Usá-lo em campanha é contato não solicitado, aumenta o risco de denúncia do número e, pela LGPD, é uso fora da finalidade que justificou a coleta. Guarde o contato ligado ao pedido e use-o só na entrega.
Sim. Quando a flor pedida não chega no mercado, a loja manda a explicação com até três botões: trocar por uma equivalente, remarcar a entrega ou falar com a loja. Cada botão carrega um identificador definido por você com o número do pedido dentro, e é ele que volta no webhook, já amarrado ao registro certo.
R$ 27 por mês por número conectado, sem cobrança por mensagem, e o limite é de 300 mensagens por dia por número — cerca de 9.000 por mês —, pensado para proteger o número da loja contra bloqueio. O teste é de 14 dias sem cartão e só começa a contar quando você conecta o primeiro número, então a integração pode ser escrita antes.
14 dias grátis, sem cartão — a contagem só começa quando você conectar o número. Crie a conta, leia o QR Code e mande a primeira prova de entrega ainda hoje.