O sistema de reservas do espaço já sabe quem pegou a sala das 14h e quantas horas sobraram no pacote de cada membro. Com a API do zapon, ele mesmo manda a confirmação, o lembrete com botão de liberar a sala e a instrução de acesso do dia — e recebe a resposta por webhook, para devolver o horário ao inventário sem passar pela recepção.
Coworking não sofre do mesmo mal que uma agenda de atendimento. Aqui o recurso é compartilhado e finito: quando alguém reserva a sala de reunião das 14h e não aparece, ela não fica apenas vazia — ficou bloqueada no painel para todos os outros membros, que viram "indisponível" e foram trabalhar na mesa flexível. O prejuízo é da comunidade antes de ser do caixa, e é por isso que a mensagem mais valiosa do fluxo não é "confirme sua reserva": é "libere a sala se não for usar".
A segunda frente é o dia a dia da recepção: o membro que não sabe o andar, o visitante que não foi autorizado na portaria, o código de entrada que não chegou. E a terceira é o contrato — plano que vence e saldo de créditos que expira sem aviso, a conversa mais desagradável do balcão. As três se resolvem pelo mesmo caminho: o sistema que já tem o dado manda a mensagem. O zapon expõe uma API REST simples — header token, JSON entrando e saindo — que o seu sistema de reservas chama como chamaria qualquer serviço.
Porque o custo não é a sala vazia, é a sala negada. Enquanto a reserva existe no sistema, o horário sai do inventário e todo mundo que tentou reservar recebeu "indisponível". Um membro que avisa às 13h50 que não vai usar devolve noventa minutos de sala para o espaço; o mesmo membro em silêncio transforma a mesma reserva em recurso perdido para a comunidade inteira.
Essa é a diferença estrutural do setor. Numa agenda de atendimento, a falta atinge quem esperava atender. Num espaço compartilhado, ela atinge outros clientes — que pagam mensalidade e sabem exatamente qual sala ficou de porta fechada a manhã toda.
Porque as perguntas do dia são sempre as mesmas e nenhuma delas depende de julgamento: qual andar, qual sala, o código de entrada de hoje, se o visitante está liberado na portaria, até que horas o espaço fica aberto. São dados que já existem no sistema de reservas e no cadastro do membro. Enquanto alguém tem que digitá-los no balcão ou responder pelo celular do espaço, cada resposta custa uma interrupção e depende de a recepção estar lá.
Três coisas: um número de WhatsApp, uma conta no zapon com esse número conectado por QR Code ou código de pareamento, e um sistema que saiba quais reservas existem hoje. Não é preciso servidor próprio, conta na Meta, aprovação de template nem aplicativo instalado no celular da recepção.
token, credencial de todas as chamadas daquele número. Conecta-se lendo o QR Code no painel (WhatsApp → Aparelhos conectados) ou por código de pareamento.Não, e é melhor não trocar. O membro responde para o número que ele já tem salvo, e o que a automação não trata fica na conversa, no WhatsApp do espaço, para uma pessoa responder. Use um número da operação, nunca o celular pessoal de quem trabalha na recepção — pessoas mudam de emprego, e a base de conversas do coworking não vai embora com elas.
Se ele roda código ou tem área de integrações, chama a API direto: uma requisição quando a reserva é criada e uma rotina curta que varre o que começa nos próximos minutos. Se é fechado, leia os dados por fora — relatório, banco, exportação — e dispare de uma ferramenta de automação. O que a API precisa saber é sempre o mesmo: telefone e texto.
Cinco etapas: (1) a reserva é criada e o membro recebe a confirmação com sala, horário e saldo de créditos; (2) pouco antes do horário sai o lembrete com o botão de liberar; (3) na chegada, a mensagem de acesso do dia entrega andar, código e autorização do visitante; (4) se o membro libera, o webhook devolve a sala ao inventário e chama quem estava na fila; (5) perto do vencimento, saem os avisos de renovação de plano e de saldo a expirar.
Repare que nenhum dos cinco passos é a mesma mensagem repetida. Cada um responde a uma pergunta diferente do membro, e o passo 2 é o único que pede resposta.
Sala, dia, horário, duração e — o detalhe que muda o comportamento — quanto de crédito aquela reserva consome e quanto sobra. Mostrar o saldo na hora da confirmação faz o membro reservar com consciência: quem enxerga que restam seis horas no mês pensa duas vezes antes de segurar a sala grande por precaução. A mensagem também valida o canal: se a entrega falhar aqui, você descobre hoje que o cadastro tem telefone errado.
Reserva de sala se decide no mesmo dia. Um lembrete na noite anterior chega antes de a reunião ser desmarcada e não serve para nada; um lembrete disparado pouco antes do horário chega exatamente quando o membro já sabe se a reunião vai acontecer. É este o momento de pedir resposta, e é aqui que entram os botões: usar, liberar ou remarcar. Uma sala devolvida ao inventário quarenta minutos antes ainda é uma sala que outro membro consegue pegar.
Andar, sala, o caminho a partir da entrada, o código de acesso válido só para aquele dia, o nome do visitante autorizado na portaria e o horário-limite dessa autorização. É informação operacional pura, e é o que apaga a fila da recepção pela manhã. Uma regra que não se negocia: mande o código do dia, nunca a credencial permanente do membro nem a senha fixa da rede do espaço. Mensagem fica no celular, celular se perde, e credencial permanente vazada abre a porta muito depois daquela reserva.
Ele toca no botão, e isso vira um evento entregue por webhook no endereço que o coworking cadastrar — um POST com a mensagem inteira: telefone, identificador, horário e o id do botão que você mesmo definiu. Do lado de cá, a sua regra devolve o horário ao inventário, estorna o crédito e avisa quem estava na fila daquela sala. É a peça que fecha o ciclo; sem ela, você automatizou o aviso e alguém ainda lê as respostas à mão.
Duas réguas separadas, disparadas por data e não por reserva. A do contrato sai com folga do fim da vigência, diz quando termina e como renovar. A do saldo avisa quantas horas expiram e até quando dá para usá-las. É o único passo do fluxo que fala de dinheiro, e o tom muda por isso: informe, ofereça o caminho, e não repita. Aviso de vencimento que vira sequência de cobrança semanal é o jeito mais rápido de o membro silenciar a conversa do espaço.
Porque a confirmação não muda nada: quem ia usar a sala continua usando, com ou sem botão. A liberação, sim, produz um efeito imediato — devolve um recurso escasso ao inventário enquanto ainda dá tempo de outra pessoa aproveitá-lo. Num espaço compartilhado, o valor da automação está em capturar a desistência, não em coletar confirmações.
Isso tem consequência prática no desenho da mensagem. O texto pergunta "vai usar?", não "confirme sua presença", porque a segunda formulação empurra todo mundo para o botão que não gera ação nenhuma. E a resposta a quem libera precisa ser generosa: crédito estornado, nada de multa, agradecimento curto. Punir quem avisa é ensinar a comunidade inteira a não avisar.
O WhatsApp permite três botões de resposta rápida, com rótulos curtos. Use os três assim: um para manter a reserva, um para liberar e um para remarcar. "Remarcar" não deve tentar resolver sozinho — casar sala, horário e disponibilidade é trabalho da recepção ou do próprio sistema de reservas; a mensagem só sinaliza a intenção e coloca aquele membro numa fila que alguém trata. Se você precisar oferecer mais opções, como escolher entre horários alternativos da mesma sala, o /chat/send/list entrega um menu em lista. 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.
Três resolvem o fluxo inteiro: POST /chat/send/text para confirmação, acesso do dia e avisos de contrato; POST /chat/send/buttons para o lembrete com liberação em um toque; e POST /user/check para conferir se o telefone do cadastro — principalmente o de visitante — tem WhatsApp. Todos usam a base https://api.zapon.dev e o header token. São 49 endpoints publicados, todos com schema, mas o fluxo de reservas vive nesses três.
A autenticação é um header só, token, copiado da conexão no painel: não é Authorization, não é Bearer, não há OAuth. Trate-o como senha — quem o tem envia mensagens em nome do espaço.
Um POST em /chat/send/text com dois campos obrigatórios: 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": "Rafael, sua reserva está confirmada.\n\nSala Ipê (6 lugares)\nQuinta, 12/03, das 14h às 15h30\nUnidade Faria Lima — 7º andar\n\nConsome 1h30 do seu pacote. Saldo depois desta reserva: 6h30.\nSe a reunião cair, responda por aqui para liberar a sala." }'
A resposta traz o identificador da mensagem no WhatsApp:
{
"code": 200,
"success": true,
"data": {
"Details": "Sent",
"Id": "A41C7D9E2B08F6135ACD",
"Timestamp": "2026-03-10T11:04:51-03:00"
}
}Guarde esse Id junto da reserva: é ele que prova qual mensagem saiu e evita reenvio duplicado quando a rotina roda duas vezes.
Ao contrário de uma agenda de atendimento, aqui não existe rotina noturna. O padrão é uma rotina curta rodando em intervalos de poucos minutos, que pega a janela à frente e dispara só o que ainda não foi avisado.
// lembretes.js — roda a cada 5 minutos const API = "https://api.zapon.dev"; const TOKEN = process.env.ZAPON_TOKEN; async function enviarBotoes(phone, body, footer, buttons) { const r = await fetch(`${API}/chat/send/buttons`, { method: "POST", headers: { "token": TOKEN, "Content-Type": "application/json" }, body: JSON.stringify({ Phone: phone, Body: body, Footer: footer, Buttons: buttons }) }); 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)); // janela: reservas que começam entre 40 e 55 minutos a partir de agora for (const res of await reservasNaJanela(40, 55)) { if (res.status !== "ativa" || res.membro.optOut) continue; if (await jaAvisado(res.id, "lembrete_dia")) continue; // a rotina roda de novo em 5 min try { const id = await enviarBotoes(res.membro.telefone, `${res.membro.nome}, a ${res.sala} está reservada para você às ${res.hora}. Vai usar?`, "Recepção — unidade Faria Lima", [ { id: `${res.id}|usar`, text: "Vou usar" }, { id: `${res.id}|liberar`, text: "Liberar sala" }, { id: `${res.id}|remarcar`, text: "Remarcar" } ]); await registrarEnvio(res.id, "lembrete_dia", id); } catch (e) { await registrarFalha(res.id, "lembrete_dia", String(e)); // vira tarefa da recepção } await pausa(3000); // não despeje a agenda do dia no mesmo segundo }
Três detalhes desse laço separam o fluxo que dura do que quebra na primeira semana. O jaAvisado é obrigatório aqui: como a rotina roda a cada cinco minutos e a janela tem quinze, a mesma reserva cai nela três vezes. O continue impede lembrete de reserva já cancelada e de quem pediu para não receber. E a pausa evita transformar um horário cheio numa rajada de dezenas de mensagens no mesmo instante — comportamento que não parece humano.
Cada botão carrega um id definido por você, e é ele que volta no webhook quando o membro toca. Coloque o número da reserva aí dentro: a resposta chega amarrada ao registro certo, sem depender do telefone e sem interpretar texto.
POST https://api.zapon.dev/chat/send/buttons token: SEU_TOKEN { "Phone": "5511999999999", "Body": "Rafael, a Sala Ipê está reservada para você às 14h. Vai usar?", "Footer": "Recepção — unidade Faria Lima", "Buttons": [ { "id": "res5521|usar", "text": "Vou usar" }, { "id": "res5521|liberar", "text": "Liberar sala" }, { "id": "res5521|remarcar", "text": "Remarcar" } ] }
O cadastro de membro costuma estar certo; o de visitante, não. Ele é digitado às pressas na portaria ou copiado de um convite. O POST /user/check recebe uma lista e diz quais números têm conta no WhatsApp — vale conferir antes de mandar a instrução de acesso para alguém que nunca vai recebê-la.
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": "" } ] } }
Ao todo são 13 formas de envio — texto, imagem, áudio, vídeo, documento, sticker, localização, contato, enquete, lista, botões, template e edição de mensagem já enviada — mais reação, "digitando", marcar como lido e histórico. Fora do trio principal, os mais úteis para um espaço compartilhado são localização, na primeira visita de um membro novo, e documento, para mandar o contrato ou o comprovante de renovação.
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 é 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á polling nem nada para ficar consultando.
O ciclo tem três partes que não se misturam: o webhook entrega o evento, a sua regra interpreta e a ação acontece no seu sistema de reservas. A API não sabe o que é uma sala; 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": "3EB0F2A18C4D9B7E6015",
"Chat": "[email protected]",
"Sender": "[email protected]",
"IsFromMe": false, "IsGroup": false,
"PushName": "Rafael Andrade",
"Timestamp": "2026-03-12T13:18:40-03:00"
},
"Message": { "conversation": "pode liberar, a reunião caiu" }
}
}
// quando ele toca num botão, muda só o bloco Message:
"Message": { "buttonsResponseMessage": {
"selectedButtonID": "res5521|liberar",
"Response": { "SelectedDisplayText": "Liberar sala" }
} }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 envia também gera evento, com IsFromMe igual a true: ignore, ou a recepção respondendo um membro aciona a sua automação.
Descarte o que não interessa, identifique a reserva pelo id do botão, aja no inventário e responda ao membro dizendo o que aconteceu — é essa última parte que evita o "liberei e não sei se valeu".
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 recepção 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 reserva = botao ? await buscarReserva(botao.split("|")[0]) : await proximaReservaPorTelefone(telefone); if (!reserva) return filaDaRecepcao(telefone, texto); const acao = botao ? botao.split("|")[1] : /^(liberar|libera|pode liberar|nao vou|não vou)/.test(texto) ? "liberar" : /^(vou usar|confirmo|sim)$/.test(texto) ? "usar" : null; if (acao === "liberar") { await devolverAoInventario(reserva); // a sala volta a aparecer como livre await estornarCredito(reserva); // quem avisa não pode ser punido await avisarFilaDaSala(reserva); // quem queria aquele horário é chamado return enviarTexto(telefone, `Sala liberada e ${reserva.horas}h devolvidas ao seu saldo. Obrigado por avisar.`); } if (acao === "usar") { await marcarPresencaEsperada(reserva.id); return enviarTexto(telefone, `Combinado. A ${reserva.sala} fica reservada até ${reserva.fim}.`); } return filaDaRecepcao(telefone, texto); // remarcação e o resto é assunto de gente });
Ele vai escrever: "consigo estender até as 17h?", "cabe mais duas pessoas nessa sala?", "meu convidado chega às 15h, dá para liberar na portaria?". Não tente responder tudo automaticamente. O que a automação não reconhece vira pendência para uma pessoa tratar — e a conversa já está no WhatsApp do espaço, então a recepção responde no próprio aplicativo, como sempre fez. O papel da automação é sinalizar que aquela conversa espera resposta, não fingir que é a recepção.
Separando o que é operacional do que é divulgação, e controlando o ritmo. Elevador parado, queda de internet, mudança de horário no fim de semana e dedetização afetam o dia de quem paga pelo espaço: é serviço. Convite de happy hour, oferta de parceiro e newsletter da comunidade são divulgação e pedem consentimento. Na hora de disparar, um laço com pausa entre os envios, lendo o descadastro antes de cada mensagem — nunca a base inteira no mesmo minuto.
Existe um segundo caminho para o aviso coletivo: o grupo. O zapon publica 18 endpoints de grupo, o que permite ao seu sistema manter e usar um grupo por unidade ou por andar para comunicados operacionais. A escolha entre grupo e mensagem individual não é técnica, é editorial: grupo funciona bem para o que todo mundo precisa saber ao mesmo tempo e mal para o que é específico de uma pessoa. Reserva, saldo e acesso são sempre individuais.
Quando ele pede algo em vez de informar algo. "A internet do 7º andar volta às 14h" é serviço. "Venha ao nosso happy hour de quinta com a marca parceira" é divulgação, mesmo quando é gratuita e bem-intencionada. A regra prática: se o membro precisaria da informação para tocar o dia dele, é operacional; se ele só precisaria dela caso quisesse participar de algo, é marketing, e marketing exige consentimento registrado e um caminho de saída que funcione.
Não. Membro ativo recebendo aviso sobre a própria reserva, o próprio acesso e o próprio contrato é comunicação esperada — ele deu o telefone para isso e o assunto é o serviço contratado. Visitante que apareceu uma vez não vira base de contato, e ex-membro não recebe campanha de volta sem consentimento. Misturar as duas coisas no mesmo canal é o erro que transforma um número útil num número denunciado.
optOut do exemplo em Node. O pedido chega em qualquer palavra ("não quero mais essas mensagens"), então alguém precisa olhar a fila de exceções todo dia.Credencial permanente, senha fixa da rede, código mestre de porta, número de cartão de acesso e qualquer coisa que continue valendo depois daquele dia. A mensagem carrega o que expira: o código do dia, o andar, a sala e o horário-limite da autorização do visitante. Se o celular do membro for perdido, o que estiver na conversa continua lá.
Escreva imaginando que a mensagem será lida por outra pessoa — a notificação aparece na tela travada, no metrô, ao lado de quem quer que esteja perto. Endereço completo da unidade somado a um código que abre a porta é um par que não deveria viajar junto. Mande o código no dia e com validade curta, e prefira que a autorização do visitante seja verificada na portaria contra o cadastro, não contra o que ele mostrar no celular.
A conversa fica no WhatsApp do espaço: quem tem acesso ao aparelho ou aos aparelhos conectados vê o histórico, inclusive de contratos e valores discutidos com membros. Isso merece o cuidado que se dá à senha do sistema de reservas — bloqueio de tela e retirada dos aparelhos conectados quando alguém deixa a equipe. E o texto que você guardar no seu banco passa a fazer parte do que precisa ser protegido.
R$ 27 por mês por número conectado, sem cobrança por mensagem: o valor não muda se o espaço mandar 80 ou 5.000 mensagens no mês. Cada número tem cota de 300 mensagens por dia, o bastante para as reservas e os acessos de um andar cheio e um limite que preserva o número do espaço contra bloqueio. O teste é de 14 dias sem cartão e a contagem só começa na primeira conexão — dá para criar a conta, escrever a integração com o sistema de reservas com calma e só depois conectar o número.
Essa previsibilidade importa mais aqui do que parece. O fluxo de um coworking tem picos: um comunicado de manutenção fala com a casa inteira de uma vez, e o número de reservas por dia varia com a semana. Com cobrança por mensagem, o comunicado que todo mundo precisa receber vira uma decisão de custo — e alguém acaba cortando justamente o aviso mais útil. Com mais de uma unidade, é uma conexão por unidade, e o seu sistema escolhe de qual número a mensagem sai trocando o header.
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, 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 quando uma chamada de envio falhar, registre numa lista visível — foi o que o registrarFalha fez — e faça a recepção olhar essa lista todo dia. Instrução de acesso que não saiu vira membro parado na portaria, então ela precisa virar tarefa, não silêncio.
Dá, sempre que esse sistema conseguir fazer uma chamada HTTP ou exportar as reservas do dia. Se ele tem área de integrações ou webhooks próprios, a reserva criada já dispara a confirmação. Se é fechado, leia os dados por fora (relatório, banco, exportação) e coloque uma ferramenta de automação no meio para chamar a API.
Disparando com ritmo e com critério. Um laço que envia com pausa entre as mensagens e consulta o descadastro antes de cada envio se comporta como uma pessoa avisando; a base inteira no mesmo minuto, não. E limite o aviso coletivo ao que é operacional: se a informação não muda o dia de quem recebe, ela não justifica falar com todo mundo.
Ele recebe a instrução de acesso daquele dia porque um membro o autorizou, e só isso. O telefone do visitante entra no cadastro para viabilizar a visita, não para virar base de campanha depois. Antes de enviar, vale passar o número pelo POST /user/check, porque cadastro de visitante costuma ser digitado às pressas.
Credencial permanente, não. Mande o que expira: o código válido só para aquele dia, com o horário-limite, e nunca a senha fixa da rede nem o código mestre de porta. A conversa fica no celular do membro por tempo indeterminado, e o que vale para sempre continua valendo se aquele aparelho se perder.
Funciona, com uma conexão por unidade. Cada conexão é um número com o seu próprio token e o seu próprio webhook, então o membro fala com a casa dele e a instrução de acesso nunca sai com o andar de outro endereço. O seu sistema escolhe de qual número a mensagem sai trocando o header da chamada.
A automação resolve metade: o lembrete com botão de liberar transforma a maior parte das desistências em sala devolvida ao inventário a tempo. A outra metade é política da casa — limite de reservas simultâneas, consumo de crédito por ausência, prioridade na fila. A mensagem informa e facilita; ela não substitui a regra do espaço.
R$ 27 por mês por número conectado, sem cobrança por mensagem, com 300 mensagens por dia em cada número. O teto acompanha a agenda de salas e os avisos de acesso de um coworking movimentado e existe para o número não ser bloqueado por excesso de envio. O teste é de 14 dias sem cartão e só começa a contar quando você conecta o primeiro número.
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 o primeiro lembrete de reserva hoje.