No delivery, o WhatsApp não é só o canal de aviso: é por onde o pedido entra. Com a API do zapon, cada mensagem que chega no número vira evento no seu sistema, o pedido ganha número e volta confirmado por escrito — e preparo, saída e entrega avisam sozinhos.
O pedido chega assim: "1 pizza grande metade calabresa, sem cebola, e uma coca 2L". Em texto solto, no meio de uma conversa com outras trinta, e some assim que a próxima mensagem empurra a anterior para cima. Às 20h de sexta, o mesmo aparelho recebe pedido novo, cliente perguntando se já saiu e cliente reclamando de atraso.
Uma API de WhatsApp ataca os dois lados. O zapon expõe uma API REST simples — header token, JSON entrando e saindo — para enviar, e um webhook que entrega ao seu sistema tudo que chega no número. É esse webhook que transforma a conversa em entrada de pedidos com número, fila e status.
Porque a conversa é uma lista cronológica, não uma fila de trabalho. Mensagem lida continua parecendo igual a mensagem tratada, e a única forma de saber o que está pendente é rolar a tela para trás. Basta um atendimento longo para um pedido subir e ficar sem resposta.
Duas perdas convivem no balcão:
Porque avisar depende de alguém sair da produção, achar a conversa certa e escrever. Com a operação cheia, esse alguém não existe. Quando a falta vira um passo do processo, o cliente é avisado no minuto em que o item é marcado como indisponível e escolhe a substituição com um toque.
Três coisas: o número que o restaurante já divulga, uma conta no zapon com esse número conectado por QR Code ou código de pareamento, e um lugar onde o pedido vire registro com número e status. Sem servidor próprio, sem conta na Meta e sem aprovação de template.
token, credencial de todas as chamadas daquele número.Não, e essa é a decisão mais importante do projeto. A API entrega o texto exatamente como o cliente digitou. Interpretar "sem cebola, capricha no orégano, se não tiver de 2L manda duas de 1L" automaticamente é armadilha: a linguagem do pedido vive de exceção e meia frase, e erro de leitura vira pizza errada na porta. A automação registra, numera, confirma e avisa. Quem fecha o pedido é uma pessoa, em dez segundos, dentro do sistema.
Seis etapas: (1) a mensagem chega pelo webhook e vira pedido com número; (2) sai a confirmação com resumo escrito, valor, pagamento e tempo estimado; (3) a cozinha começa e o cliente é avisado — faltou item, ele escolhe a troca por botões; (4) o pedido sai com nome do entregador e previsão; (5) a entrega fecha o pedido; (6) a avaliação vem logo depois.
Cada passo existe por um motivo diferente. Não é a mesma frase repetida cinco vezes.
O cliente escreve como sempre fez. A diferença é que a mensagem não fica só na tela: o webhook a entrega por POST, com telefone, nome do contato, horário, identificador e o texto íntegro. Seu sistema grava um rascunho, gera um número e devolve o recibo — "Recebemos, seu pedido é o #1482". Uma frase que tira a ansiedade e cria o identificador de todas as mensagens seguintes.
Depois que alguém confere o pedido, sai a confirmação — e é ela que evita a discussão na porta. Repita os itens por escrito, com as observações do cliente, e some valor total, taxa de entrega, endereço entendido, forma de pagamento, troco combinado e tempo estimado. Divergência descoberta aqui custa trinta segundos; a mesma divergência na porta custa o pedido.
Na entrada em produção sai um aviso curto: "Pedido #1482 em preparo. Saída prevista: 20h40". É o que faz o cliente parar de perguntar. E aqui mora o caso chato: o item que acabou. Em vez de mandar o pedido incompleto e torcer, dispare botões com a substituição — sabor equivalente, outra bebida, ou tirar o item e abater do valor. A escolha volta pelo webhook amarrada ao número do pedido.
É o aviso que mais corta ligação. Quatro informações: número do pedido, nome do entregador, forma de pagamento que ele vai apresentar (com o troco, quando for dinheiro) e previsão de chegada. Escrever o pagamento aqui resolve na origem a briga mais comum do portão — "eu tinha combinado cartão" —, que hoje acontece com o entregador parado, sem poder decidir nada.
Na baixa sai a confirmação curta de fechamento; o cliente já está com a comida na mão. O que importa é o outro caso: entrega frustrada — ninguém atendeu o interfone, endereço errado, valor diferente do combinado. Isso não vira mensagem automática nem pedido pendurado: vira tarefa de gente, tratada enquanto o entregador ainda está na rua.
Logo depois, trinta ou quarenta minutos após a entrega, com resposta de um toque e sem formulário. Nota baixa não merece desculpa automática: vira pendência para alguém do restaurante responder como pessoa. E repare que a avaliação ainda trata do pedido que aquele cliente fez. A promoção da semana é outro fluxo, com outro consentimento.
Quatro resolvem a operação: POST /chat/send/text para os avisos de status, POST /chat/send/buttons para confirmar e para trocar item em falta, POST /chat/send/image para o cardápio sob demanda e POST /user/check para validar telefone. Base https://api.zapon.dev, header token. São 49 endpoints publicados, mas o pedido vive nesses quatro.
Autenticação é um header só, token, copiado da conexão no painel — nada de Bearer nem OAuth. Trate como senha do caixa: quem tem o token fala em nome do restaurante.
Um POST em /chat/send/text com Phone, o número 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 #1482 confirmado — Pizzaria Exemplo\n\n1x Pizza grande: metade calabresa, metade mussarela (sem cebola)\n1x Refrigerante 2L\n\nSubtotal: R$ 68,00\nEntrega: R$ 8,00\nTotal: R$ 76,00\n\nPagamento: dinheiro, troco para R$ 100,00\nEndereço: Rua das Acácias, 120, apto 42\nPrevisão: 50 a 60 minutos" }'
A resposta devolve o identificador da mensagem:
{
"code": 200,
"success": true,
"data": {
"Details": "Sent",
"Id": "90B2F8B13FAC8A9CF6B06E99C7834DC5",
"Timestamp": "2026-03-01T20:12:08-03:00"
}
}Grave esse Id por pedido e por status. É ele que prova qual aviso já saiu e impede que uma correção de comanda dispare o mesmo "saiu para entrega" duas vezes.
O desenho que sobrevive ao pico é uma rotina curta, de minuto em minuto, que pega as mudanças de status ainda não avisadas e envia uma a uma. Não é disparo em massa: é uma fila que se esvazia enquanto a equipe monta as sacolas.
// status.js — roda a cada minuto durante o expediente 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)); const textos = { preparo: (p) => `Pedido #${p.numero} em preparo. Saída prevista: ${p.saidaPrevista}.`, a_caminho: (p) => `Pedido #${p.numero} saiu para entrega com ${p.entregador}.\n` + `Pagamento: ${p.pagamento}. Chega em cerca de ${p.etaMin} minutos.`, entregue: (p) => `Pedido #${p.numero} entregue. Obrigado por pedir na Pizzaria Exemplo!` }; for (const p of await mudancasDeStatusPendentes()) { if (await jaAvisado(p.id, p.status)) continue; // nunca o mesmo aviso 2x const montar = textos[p.status]; if (!montar) continue; // status interno não vira mensagem try { const id = await enviarTexto(p.telefone, montar(p)); await registrarAviso(p.id, p.status, id); // guarda o Id do envio } catch (e) { await registrarFalha(p.id, p.status, String(e)); // vira tarefa do balcão } await pausa(3000); // ritmo humano, mesmo com a fila cheia }
Três linhas fazem esse laço durar. O jaAvisado grava o par pedido + status, então reiniciar o processo no meio do pico não reenvia nada. O registrarFalha converte erro em tarefa visível — aviso que não saiu precisa aparecer para alguém. E a pausa mantém um ritmo de restaurante: cinquenta mensagens no mesmo segundo não parecem operação.
/chat/send/buttons envia botões de resposta rápida. Cada um carrega um id definido por você, e é esse id que retorna no webhook. Ponha o número do pedido dentro dele: a resposta chega presa ao registro certo, sem depender do telefone — o que importa quando o mesmo cliente pede duas vezes na mesma noite. 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 #1482: 1 pizza grande (calabresa/mussarela, sem cebola) e 1 refrigerante 2L. Total R$ 76,00 com entrega. Confirma?", "Footer": "Pizzaria Exemplo", "Buttons": [ { "id": "p1482|confirmar", "text": "Confirmar" }, { "id": "p1482|trocar", "text": "Trocar item" }, { "id": "p1482|cancelar", "text": "Cancelar" } ] }
O mesmo endpoint resolve o item em falta, trocando as opções pelas substituições que a cozinha aceita naquele momento:
{
"Phone": "5511999999999",
"Body": "Pedido #1482: acabou o refrigerante de 2L. Como prefere resolver?",
"Footer": "Pizzaria Exemplo",
"Buttons": [
{ "id": "p1482|troca|2x1L", "text": "2 de 1L" },
{ "id": "p1482|troca|suco", "text": "Suco 1L" },
{ "id": "p1482|troca|retira", "text": "Tirar do pedido" }
]
}O rótulo cabe em 20 caracteres, então uma ou duas palavras. Se a lista de substituições passar de três opções, o envio em formato de lista dá conta do menu maior.
Pode: o cliente pergunta "tem cardápio?" e o sistema devolve a imagem do dia. Em /chat/send/image, o campo Image aceita URL ou data URI em base64, e o Caption viaja junto da foto.
curl -X POST https://api.zapon.dev/chat/send/image \ -H "token: SEU_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "Phone": "5511999999999", "Image": "https://exemplo.com.br/cardapio/2026-03-01.jpg", "Caption": "Cardápio de hoje. Responda por aqui com o que você quer — confirmamos tudo por escrito antes de preparar." }'
A palavra que separa isso de um problema é demanda. Cardápio para quem pediu é atendimento. O mesmo arquivo disparado para mil números frios é propaganda não solicitada, e é o atalho mais rápido para o bloqueio, porque junta muita denúncia no mesmo intervalo.
Cadastro de delivery junta telefone fixo, número antigo e dígito faltando. POST /user/check recebe uma lista e informa quais têm conta.
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": "" } ] } }
A conta toda soma 13 formas de envio — além de texto, imagem e botões, há áudio, vídeo, documento, sticker, localização, contato, enquete, lista, template e a edição de mensagem já enviada —, mais reação, presença, marcação de leitura e histórico. Num delivery, os dois extras que rendem são localização, para a retirada no balcão, e enquete, para a avaliação.
Cada conexão tem webhook próprio: você cadastra a URL do seu sistema no painel e escolhe os eventos. A partir daí, tudo que chega naquele número é entregue como POST, com o conteúdo inteiro no corpo — telefone, nome do contato, horário, identificador, o texto do pedido e, em resposta de botão, o id que você definiu. Sem polling e sem tela para vigiar.
É aqui que esta página se separa das outras da família: no delivery, o webhook é a porta de entrada do pedido, não só o caminho de volta da resposta.
Assim chega o pedido escrito à mão:
{
"type": "Message",
"event": {
"Info": {
"ID": "3EB0C767D26A1B5F7C83",
"Chat": "[email protected]",
"Sender": "[email protected]",
"IsFromMe": false, "IsGroup": false,
"PushName": "Marcos Ribeiro",
"Timestamp": "2026-03-01T20:04:22-03:00"
},
"Message": { "conversation": "1 pizza grande metade calabresa, sem cebola, e uma coca 2L" }
}
}
// no toque de um botão, muda só o bloco Message:
"Message": { "buttonsResponseMessage": {
"selectedButtonID": "p1482|confirmar",
"Response": { "SelectedDisplayText": "Confirmar" }
} }Dois cuidados poupam uma tarde de depuração. O corpo pode vir como JSON puro ou como formulário codificado com o JSON dentro de um campo — aceite as duas formas. E o que o próprio número envia também gera evento, marcado com IsFromMe verdadeiro: se você não descartar, a atendente respondendo um cliente abre um pedido fantasma.
A regra é curta de propósito: botão tem tratamento determinístico, porque o identificador é seu; texto solto vira rascunho e vai para a fila do balcão, sem adivinhação.
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(); if (botao) { // formato: p1482|acao|opcao const [ref, acao, opcao] = botao.split("|"); const pedido = await buscarPedido(ref); if (!pedido) return filaDoBalcao(telefone, botao); if (acao === "confirmar") { await mudarStatus(pedido.id, "em_preparo"); return enviarTexto(telefone, `Pedido #${pedido.numero} confirmado, já foi para a cozinha.`); } if (acao === "troca") { await substituirItem(pedido.id, opcao); // recalcula o total return enviarTexto(telefone, `Trocado. Novo total: ${await totalFormatado(pedido.id)}.`); } return filaDoBalcao(telefone, botao); // trocar item e cancelar: gente decide } if (!await estamosAbertos()) { // fora do expediente await filaDoBalcao(telefone, texto); return enviarTexto(telefone, "Estamos fechados agora. Abrimos amanhã às 18h e respondemos por aqui."); } const pedido = await abrirRascunho({ telefone, nome: info.PushName, texto }); await marcarComoLido(info.ID); // o cliente vê que foi visto return enviarTexto(telefone, `Recebemos! Seu pedido é o #${pedido.numero}. Vamos conferir e já confirmamos por escrito.`); });
Repare no que esse código não faz: não lê os itens, não calcula valor a partir do texto e não decide cancelamento. Numera, registra, avisa e chama gente quando o assunto exige gente.
Ajudam, por um motivo simples: no pico, o que irrita não é esperar, é não saber se foi visto. Marcar a mensagem como lida assim que ela vira registro dá esse sinal. A presença de "digitando", por poucos segundos antes de uma resposta que vai demorar a ser montada, tem o mesmo efeito. Usar os dois quando ninguém vai responder de fato só piora a percepção.
O pior desfecho é o pedido da meia-noite ficar mudo até as 18h. A mensagem automática fora do expediente resolve, desde que seja honesta: diga que está fechado, diga quando abre e diga que a mensagem ficou registrada. Nada de "responderemos em breve" quando breve são dezoito horas. E guarde o texto na fila: ele é o primeiro pedido do dia seguinte.
Mensagem sobre um pedido que o cliente acabou de fazer é esperada: ele deu o telefone para isso. Promoção, cardápio novo e cupom são outra categoria, e exigem consentimento explícito, registrado com data, mais um caminho fácil de descadastro. Disparar oferta para todo mundo que já pediu uma vez é exatamente o comportamento que faz um número ser denunciado.
Escreva a forma de pagamento combinada e, em dinheiro, o valor do troco — no aviso de saída, não antes. É o que evita a discussão no portão, com o entregador parado e sem poder resolver. O que nunca entra na conversa é dado de cartão: número, validade e código de segurança não se pedem por mensagem, nem por foto.
A conversa fica gravada nos dois aparelhos e passa por quem tem acesso aos aparelhos conectados; um número de cartão escrito ali continua ali no mês seguinte. Pagamento antecipado se resolve com link ou código de cobrança do seu gateway. Endereço, ponto de referência e nome já são dado pessoal: guarde o necessário para entregar e proteja o resto como se protege a senha do caixa.
R$ 27 por mês por número conectado, sem cobrança por mensagem: o valor é o mesmo numa terça de 20 pedidos e num sábado de 300. Cada número tem cota de 300 mensagens por dia — cerca de 9.000 por mês — que segura o ritmo de envio para o WhatsApp não bloquear o número do restaurante. O teste dura 14 dias sem cartão e a contagem só começa na primeira conexão, então dá para escrever a integração com calma antes de conectar.
Essa previsibilidade é o que viabiliza o fluxo inteiro. São quatro ou cinco mensagens por pedido, e num modelo de cobrança por mensagem o custo cresceria junto com o movimento até alguém cortar justamente o aviso de saída — o que mais evita ligação. Com duas lojas, são duas conexões, e o seu sistema escolhe de qual número a mensagem sai trocando o header.
A pergunta é sobre o seu desenho, não sobre a API. O que trava no pico é fluxo síncrono: se o webhook processa o pedido antes de responder, uma rajada vira fila parada. Por isso o receptor devolve 200 na primeira linha e trabalha depois, e os avisos saem de uma fila com pausa, que se esvazia em segundos enquanto a equipe monta as sacolas.
O painel mostra o estado de cada conexão e atualiza a cada 10 segundos com a página aberta — deixar essa aba num monitor do balcão já cobre boa parte do turno. Para não depender de olho humano, assine os eventos de conexão no webhook: Disconnected avisa a queda, LoggedOut avisa que o número precisa reler o QR Code. E o que o registrarFalha gravou tem que aparecer numa lista conferida durante o expediente.
Dá, e é o ponto central desta integração. Cada mensagem que chega no número conectado é entregue ao seu sistema por webhook, com telefone, nome do contato, horário e o texto íntegro. O sistema grava um pedido em rascunho, gera um número e responde na hora com o recibo. A conversa deixa de ser uma caixa que alguém vigia e vira entrada de pedidos com fila e status.
Não, e não é o que você deve querer. A API entrega o texto exatamente como o cliente digitou; interpretar "sem cebola, capricha no orégano" automaticamente termina em pedido errado na porta. O papel da automação é registrar, numerar, confirmar por escrito e avisar cada status. Quem lê o texto e fecha o pedido é uma pessoa, dentro do seu sistema.
Aguenta se o desenho for assíncrono. O receptor do webhook responde 200 imediatamente e processa depois, e os avisos de status saem de uma fila com pausa entre envios, que se esvazia enquanto a equipe monta os pedidos. O que trava no pico é fluxo síncrono e tentativa de mandar tudo no mesmo instante, não o volume em si.
Mandar o cardápio para quem pediu o cardápio é atendimento, e o endpoint de imagem faz isso em uma chamada. Disparar o mesmo arquivo para uma lista fria é propaganda não solicitada e é o atalho mais rápido para o bloqueio, porque junta muita denúncia no mesmo intervalo. A diferença não está na ferramenta, está em quem pediu para receber.
Ele pergunta porque não foi avisado. Com preparo, saída e entrega saindo sozinhos a cada mudança de status, a pergunta some da maior parte dos pedidos. Quando ainda assim aparecer, a mensagem chega pelo webhook e o seu sistema pode responder com o status atual do pedido daquele telefone, sem interromper quem está montando a sacola.
Dá, e costuma ser o melhor arranjo: o cliente pede para o número que está no cardápio e na fachada, e a equipe continua atendendo no aparelho. A automação cuida do repetitivo — numerar, confirmar, avisar status — e deixa visível na conversa o que precisa de resposta humana, como reserva de mesa e dúvida sobre ingrediente.
R$ 27 por mês por número conectado, sem cobrança por mensagem, com cota de 300 mensagens por dia por número (cerca de 9.000 por mês). O valor não muda entre uma terça fraca e um sábado cheio, e é isso que viabiliza mandar todos os avisos em vez de cortar os mais caros; a cota existe para proteger o número contra bloqueio do WhatsApp. O teste é de 14 dias sem cartão e só começa a contar quando você conecta o primeiro número.
Só para quem consentiu explicitamente em receber divulgação, com registro de quando isso aconteceu, e sempre com um caminho fácil de descadastro. Promoção é fluxo separado do status do pedido: quem sai da lista de divulgação continua recebendo os avisos do pedido que fizer depois. Misturar as duas coisas no mesmo disparo é o erro que transforma o número do restaurante num número denunciado.
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 receba o primeiro pedido numerado hoje à noite.