O problema de quem vende software para restaurante
Quem opera uma plataforma de cardápio digital ou de gestão de pedidos conhece a cena: o cliente pediu às 19h40, o pedido saiu às 20h15 e ele ligou três vezes perguntando onde estava a comida. O restaurante culpa o motoboy, o motoboy culpa a cozinha e o suporte da sua plataforma recebe o chamado.
O WhatsApp resolve isso quando o aviso sai sozinho, disparado pela mudança de status que já existe no seu sistema. Só que o restaurante não quer um número genérico da plataforma falando com o cliente dele. Ele quer que a mensagem venha do WhatsApp da pizzaria, o mesmo que está no Instagram e na embalagem. Por isso a conta é uma conexão por restaurante, e a sua plataforma precisa gerenciar centenas delas.
A jornada do pedido em mensagens
Cada transição de status do pedido é um gatilho natural. A tabela abaixo mostra como uma plataforma de delivery costuma mapear eventos internos para mensagens:
| Evento no seu sistema | Mensagem ao cliente | Recurso da API |
|---|---|---|
| Pedido criado | Resumo dos itens, total e forma de pagamento | Texto |
| Restaurante aceitou | Pedido confirmado, previsão de preparo | Texto |
| Em preparo | Aviso curto, sem repetir o resumo | Texto |
| Saiu para entrega | Nome do entregador e link de acompanhamento | Botão de link (CTA) |
| Entregue | Agradecimento e convite para avaliar | Lista com notas |
| Cliente sem pedido há 30 dias | Cardápio da semana, só para quem aceitou receber | Lista de itens |
Repare que nem todo status merece mensagem. Cinco avisos num pedido de 40 minutos incomodam. Muitas plataformas deixam o restaurante escolher quais etapas notificam, e isso vira configuração dentro do seu painel, não da API.
Cardápio por lista interativa
Para pedidos recorrentes, o formato de lista funciona melhor que um link para o cardápio completo. O cliente toca em "Ver cardápio", escolhe um item e o seu webhook recebe o identificador da linha escolhida. Cada lista aceita até 10 seções com até 10 itens cada, o que cobre bem um menu do dia ou os mais pedidos. Para o cardápio inteiro, continue mandando o link.
import { DApi } from 'd-api-sdk'
const dapi = new DApi({ apiKey: process.env.DAPI_KEY! })
await dapi.interactive.sendList({
sessionId: 'rest-4821', // uma conexão por restaurante
to: '5511999999999',
title: 'Cantina da Rua 9',
description: 'Pratos de hoje. Toque para escolher.',
buttonText: 'Ver cardápio',
sections: [
{ title: 'Massas', rows: [
{ rowId: 'sku-112', title: 'Lasanha bolonhesa', description: 'R$ 42,00' },
{ rowId: 'sku-118', title: 'Nhoque ao sugo', description: 'R$ 36,00' },
] },
{ title: 'Bebidas', rows: [
{ rowId: 'sku-301', title: 'Suco de laranja 500ml', description: 'R$ 12,00' },
] },
],
})Quando o cliente escolhe, chega um messages.received com type: "list_response" e o campo selected_row_id com o SKU. O resto é regra do seu carrinho. Mais formatos estão em botões e listas no WhatsApp.
O pico das 12h e das 20h
Delivery tem uma curva de uso que poucos segmentos têm: duas janelas curtas concentram boa parte dos pedidos do dia. Uma integração que responde bem às 15h pode travar às 20h, e quase sempre o gargalo está no lado da plataforma, que chama a API dentro da mesma requisição que muda o status do pedido.
Três decisões evitam isso:
- Tire o envio da requisição do painel. O restaurante clica em "saiu para entrega", o seu backend grava o status e publica um job. Um worker faz a chamada à API. Se algo atrasar, o painel da cozinha não trava.
- Use o modo assíncrono quando fizer sentido. Os envios aceitam
async: true, que devolve umcommandIdpara consulta posterior em/api/v1/commands/{id}. - Isole por restaurante. Na D-API cada conexão roda em ambiente isolado e com IP próprio, então o restaurante que deu problema às 20h não arrasta os outros.
Roteiro de implementação para a sua plataforma
- Onboarding do restaurante: na tela de integrações do seu painel, o dono clica em "Conectar WhatsApp". O backend chama
POST /api/v1/sessionscom umsessionIdderivado do id da loja e mostra o QR Code retornado por/sessions/{id}/qr. - Webhook único: configure a mesma URL para todas as conexões. O campo
sessionIdno envelope diz de qual restaurante veio cada evento. - Mapeamento de status: ligue cada transição do pedido a um template de texto editável pelo restaurante, com variáveis como nome, número do pedido e previsão.
- Monitoramento: trate
connection.statuse mostre um alerta no painel quando a loja desconectar. Melhor o dono descobrir às 17h do que o cliente às 20h. - Respostas do cliente: mensagens que não são resposta de lista vão para a caixa de atendimento do restaurante, se a sua plataforma tiver uma, ou ficam no celular da loja.
Custo previsível para margem apertada
Plataforma de delivery vive de ticket baixo e muitos pedidos. Se cada aviso de status tiver custo, a conta cresce junto com o sucesso do restaurante, e alguém precisa decidir quais mensagens cortar. Na API de WhatsApp da D-API a cobrança é por conexão, não por mensagem, e o valor por conexão cai conforme a sua base de restaurantes cresce. As faixas estão em preços.
Se a sua plataforma atende outros segmentos além de restaurante, a visão geral de produto está em API de WhatsApp para SaaS. Para o detalhe de como o aviso de rota funciona em outras operações, veja rastreio de pedidos pelo WhatsApp. E, antes de ligar a campanha de "cardápio da semana" para toda a base, leia como evitar banimento. O teste é de 14 dias grátis falando com o time comercial, com a implementação acompanhada num grupo de WhatsApp.
