O portal entrega o lead com o código do anúncio e o telefone; o que falta é a mensagem sair antes de o interesse passar. Com a API do zapon, o sistema da imobiliária responde em segundos, qualifica em botões, agenda a visita, manda a ficha do imóvel em PDF e recebe a resposta do cliente por webhook — para o corretor entrar na conversa já sabendo o que perguntar.
Captação não costuma ser o gargalo da imobiliária. O gargalo está nos minutos seguintes a um lead cair: o portal manda o contato, ele entra numa fila, o corretor está em visita, e quando alguém liga o cliente já falou com outras três imobiliárias — ou nem lembra qual anúncio abriu.
Esse intervalo é o que uma API de WhatsApp fecha. O zapon expõe uma API REST direta — header token, JSON entrando e saindo — que o seu CRM imobiliário, o seu site ou a sua rotina de integração chama como chamaria qualquer serviço. A seguir: o fluxo em cinco etapas, os endpoints em cURL e Node, o evento que volta quando o cliente responde e as regras que evitam transformar o número institucional num número denunciado.
Porque quem preenche um formulário de anúncio nunca preenche um só. O interesse é comparativo e tem prazo curto: a pessoa está com a aba aberta, olhando três imóveis parecidos. Quem responde primeiro conversa; quem responde à tarde entra numa conversa que já começou com outro. Uma mensagem automática que chega em segundos e diz de qual imóvel se trata não fecha negócio, mas segura a pessoa até o corretor assumir.
São três buracos, cada um com um remédio diferente:
Porque visita é marcada com dias de antecedência e nunca mais confirmada. O cliente muda de ideia, resolve ver outro bairro, o cônjuge não pode no sábado — e nada disso volta para a imobiliária, porque avisar dá trabalho. Um lembrete na véspera com resposta em um toque troca o silêncio por informação: quem vem confirma, quem desistiu libera o corretor e as chaves para outro atendimento do plantão.
Três peças: um número de WhatsApp da imobiliária, uma conexão no zapon com esse número lido por QR Code ou código de pareamento, e algo que saiba que o lead chegou — o CRM imobiliário, o formulário do site ou a integração que recebe o lead do portal. Não é preciso servidor próprio, conta na Meta, aprovação de template nem aplicativo instalado em aparelho nenhum.
token, credencial de todas as chamadas daquele número. Se cada loja divulga um número, é uma conexão por loja.Dá, e é o arranjo certo. O cliente responde para o número que ele viu no portal, o histórico fica na empresa e o que a automação não trata continua visível para o corretor responder à mão. O que não vale é apontar a integração para o celular pessoal de um funcionário — nem para um número novo que ninguém divulga, porque aí o cliente recebe mensagem de um desconhecido citando um imóvel.
Os dois caminhos existem. Se o CRM permite chamar uma URL quando o lead entra ou quando a visita é agendada, ele mesmo chama a API. Se é fechado, ponha uma rotina no meio, lendo os leads novos por relatório, banco ou integração de recebimento. A API precisa de duas informações — telefone e texto —, então o que muda é só de onde esses campos saem.
Cinco etapas: (1) o lead cai do portal ou do site e recebe em segundos uma mensagem citando o código do anúncio; (2) uma qualificação curta em botões separa comprar, alugar e pesquisa; (3) a visita é agendada com data, hora, referência do endereço e o que levar; (4) sai um lembrete na véspera e outro no dia, e a resposta volta por webhook; (5) depois da visita, o follow-up pergunta o que achou e oferece um imóvel parecido. O corretor entra em qualquer ponto — a automação não disputa a vaga dele.
Cada etapa tem um objetivo diferente, e nenhuma delas tenta vender imóvel por mensagem.
Assim que o lead entra, o sistema envia uma mensagem que faz duas coisas: diz de qual imóvel se trata, com o código do anúncio, e avisa que um corretor continua dali. O código importa mais do que parece — quem pediu contato sobre três apartamentos precisa saber qual chegou. Cabe uma pergunta simples aí, nada de questionário: renda e nome completo no primeiro contato espantam.
Botões. Uma pergunta por vez, no máximo três opções, rótulo curto — a finalidade (Comprar, Alugar, Só pesquisando) ou a faixa de horário para visitar. Cada botão carrega um identificador definido por você, e é ele que volta no webhook: a resposta chega amarrada ao lead certo sem interpretar texto. Quem responde "só pesquisando" não é lead ruim, é lead de outro momento — marque assim no CRM em vez de queimar o corretor nele.
A mensagem de agendamento leva data, dia da semana, horário, a referência do endereço (rua e bairro, ou o ponto de encontro) e o que levar — documento com foto costuma bastar. A localização exata e o número da unidade saem depois da visita confirmada: o imóvel pode estar ocupado, e o proprietário não autorizou que o endereço circulasse por mensagem. Entre as 13 formas de envio há localização e imagem, úteis nesse ponto — mas é decisão de política da imobiliária, não de tecnologia.
Uma rotina diária varre as visitas do dia seguinte e manda o lembrete pedindo confirmação; outra, horas antes, manda uma mensagem curta com o ponto de encontro e o nome do corretor. A resposta volta por webhook, e é aí que a véspera vira informação: visita confirmada libera o corretor para pegar as chaves; visita desmarcada devolve o horário ao plantão. Leia o status no momento do envio, para não lembrar de visita já cancelada.
No dia seguinte, uma mensagem só: o que achou do imóvel, e quer ver outro parecido? A resposta separa três destinos — quem gostou vai para a fila de proposta com o corretor, quem não gostou afina o critério da próxima sugestão, quem não responde entra numa régua com intervalo crescente e um fim. E quando o cliente escreve algo que não é resposta de botão, a conversa vira pendência do corretor, não tentativa de resposta automática.
Quatro dão conta: POST /chat/send/text para as mensagens do fluxo, POST /chat/send/buttons para a qualificação e a confirmação de visita, POST /chat/send/document para a ficha do imóvel em PDF e POST /user/check para conferir quais telefones da carteira têm WhatsApp. Todos na base https://api.zapon.dev, com o header token. São 49 endpoints publicados — 23 de /chat, 18 de /group e 8 de /user —, mas o ciclo do lead vive nesses quatro.
A autenticação é um header só, token, copiado da conexão no painel: não é Authorization, não é Bearer, não há OAuth. Trate como senha do número — quem tem o token fala em nome da imobiliária.
Um POST em /chat/send/text com dois campos obrigatórios: Phone, 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": "Olá, Marcos. Recebemos seu contato sobre o apartamento AP2317 — Vila Mariana, 68 m², 2 dormitórios.\n\nUm corretor assume esta conversa em instantes. Enquanto isso: prefere visitar em dia útil ou no fim de semana?" }'
A resposta traz o identificador da mensagem dentro do WhatsApp:
{
"code": 200,
"success": true,
"data": {
"Details": "Sent",
"Id": "90B2F8B13FAC8A9CF6B06E99C7834DC5",
"Timestamp": "2026-03-01T09:12:08-03:00"
}
}Grave esse Id no registro do lead: ele prova que a mensagem saiu e quando, e evita reenvio se a rotina rodar duas vezes.
O /chat/send/buttons envia botões de resposta rápida, com rótulo curto — o WhatsApp corta texto longo. Ponha o número do lead dentro do id de cada botão e a resposta volta identificada. 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": "Sobre o AP2317: você procura para comprar ou para alugar? Assim já direciono para o corretor certo.", "Footer": "Imobiliária Exemplo", "Buttons": [ { "id": "ld9043|venda", "text": "Comprar" }, { "id": "ld9043|locacao", "text": "Alugar" }, { "id": "ld9043|pesquisa", "text": "Só pesquisando" } ] }
Locação e venda não são o mesmo atendimento: mudam o corretor, os documentos e o que a pessoa quer saber. Separar isso no primeiro minuto poupa a conversa inteira. Para mais de três opções — horários de visita, por exemplo — o /chat/send/list entrega um menu em lista.
O /chat/send/document recebe o arquivo em data URI base64, o nome com que ele aparece na conversa e uma legenda opcional. Nome de arquivo é parte da mensagem: ficha-AP2317-vila-mariana.pdf se explica sozinho na lista de mídia do cliente, documento.pdf não.
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,JVBERi0xLjQKJcfs…", "FileName": "ficha-AP2317-vila-mariana.pdf", "Caption": "Ficha do AP2317: metragem, planta, valor de condomínio e IPTU." }'
Mande a ficha depois de saber a finalidade: PDF sem contexto vira anexo não aberto. E mantenha uma versão só — ficha antiga circulando com valor de condomínio desatualizado é retrabalho na hora da proposta.
Uma rotina agendada varre as visitas de amanhã, monta o texto e chama a API. Em Node:
// visitas-amanha.js — roda todo dia às 17h 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 intervalo = (ms) => new Promise((r) => setTimeout(r, ms)); for (const v of await visitasDeAmanha()) { if (v.status !== "agendada" || v.cliente.semContato) continue; try { const id = await enviarTexto(v.cliente.telefone, `${v.cliente.nome}, sua visita ao ${v.imovel.codigo} é amanhã, ${v.data}, às ${v.hora}.\n\n` + `Encontro com ${v.corretor.nome} em ${v.pontoDeEncontro}. Leve um documento com foto.\n` + `Responda 1 para confirmar ou 2 para remarcar.`); await registrarEnvio(v.id, "lembrete_visita", id); // o Id evita duplicar } catch (e) { await registrarFalha(v.id, "lembrete_visita", String(e)); // vira tarefa de alguém } await intervalo(4000); // nada de despejar a agenda no mesmo segundo }
Três detalhes desse laço separam a rotina que dura da que quebra na primeira semana. O continue impede lembrete de visita cancelada e de quem pediu para não receber. O registrarEnvio guarda o Id, então rodar a rotina duas vezes não manda a mesma mensagem duas vezes. E o intervalo entre envios mantém o ritmo parecido com o de uma imobiliária de verdade — uma rajada de centenas de mensagens no mesmo instante não parece.
Carteira acumulada tem telefone fixo, número trocado e dígito faltando. O POST /user/check recebe uma lista e diz quais números têm conta no WhatsApp — serve para não gastar envio em contato morto e para saber o tamanho real da base.
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": "" } ] } }
Uma ressalva: saber que o número existe não autoriza falar com ele. O /user/check resolve a base suja, não o consentimento — assunto de duas seções adiante.
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 recebida naquele número vira 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. É assim que "o cliente confirmou a visita" chega ao CRM sem ninguém copiar nada da tela do celular.
São três partes que não se confundem: o webhook entrega o evento, a sua regra interpreta e a ação acontece no seu sistema. A API não sabe o que é visita nem o que é lead; sabe que uma mensagem chegou naquele número.
O corpo traz o tipo do evento e a mensagem completa. Assim chega quem digitou "1":
{
"type": "Message",
"event": {
"Info": {
"ID": "3EB0C767D26A1B5F7C83",
"Chat": "[email protected]",
"Sender": "[email protected]",
"IsFromMe": false, "IsGroup": false,
"PushName": "Marcos Ribeiro",
"Timestamp": "2026-03-11T18:04:22-03:00"
},
"Message": { "conversation": "1" }
}
}
// tocando num botão, muda só o bloco Message:
"Message": { "buttonsResponseMessage": {
"selectedButtonID": "ld9043|locacao",
"Response": { "SelectedDisplayText": "Alugar" }
} }Duas observações 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: se não ignorar, o corretor respondendo um cliente no aparelho aciona a sua automação.
Descarte o que não interessa, encontre o lead, decida pela intenção e devolva uma confirmação curta — é isso que evita o "respondi e ninguém falou mais comigo".
app.post("/zapon/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 saiu da imobiliária, fora if (await jaTratado(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 lead = botao ? await buscarLead(botao.split("|")[0]) : await leadAtivoPorTelefone(telefone); if (!lead) return filaDoPlantao(telefone, texto); const intencao = botao ? botao.split("|")[1] : /^(1|confirmo|confirmado)$/.test(texto) ? "confirmar" : /^(2|remarcar|outro dia)$/.test(texto) ? "remarcar" : null; if (intencao === "venda" || intencao === "locacao") { await marcarFinalidade(lead.id, intencao); await atribuirCorretor(lead.id, intencao); // carteira de venda ≠ de locação return enviarTexto(telefone, "Perfeito. Já estou passando para o corretor responsável."); } if (intencao === "pesquisa") { await moverParaNutricao(lead.id); // não queime corretor nesse lead return enviarTexto(telefone, "Combinado. Aviso quando entrar algo parecido na carteira."); } if (intencao === "confirmar") { await confirmarVisita(lead.visitaId); return enviarTexto(telefone, "Visita confirmada. Até amanhã."); } if (intencao === "remarcar") { await liberarAgendaDoCorretor(lead.visitaId); return enviarTexto(telefone, "Sem problema. O corretor chama você com outros horários."); } return filaDoPlantao(telefone, texto); // o resto é assunto de gente });
Ele vai escrever — "quanto é o condomínio?", "aceita financiamento?", "a chave está com vocês?". Não tente responder isso automaticamente: valor de condomínio e IPTU muda, vaga depende da unidade, e informação errada por escrito volta na negociação. O que a automação não reconhece vira pendência do corretor daquele lead, com telefone, código do imóvel e o que a pessoa escreveu; ele responde no próprio WhatsApp, como sempre fez. O papel da automação é apontar a conversa que espera alguém.
Não. Quem preencheu o formulário do portal hoje espera contato sobre aquele imóvel — isso é atendimento pedido. Uma carteira de leads de dois anos atrás não é lista de disparo: quem perguntou de um sobrado em 2024 não pediu para receber lançamento em 2026. A separação prática é simples: responder a um pedido é uma coisa; oferecer sem ter sido chamado é outra, e essa segunda exige consentimento registrado e descadastro que funcione.
semContato do exemplo em Node. O pedido chega em qualquer palavra ("não quero mais"), então alguém precisa olhar a fila de exceções todo dia.O lead cai no número da imobiliária, a automação responde e qualifica, e o corretor assume a conversa no aparelho conectado — ele digita no WhatsApp normalmente, sem aprender ferramenta nova. A API e as pessoas dividem o mesmo número: o que é previsível (primeira resposta, lembrete de visita, follow-up) sai do sistema; o que exige negociação sai do corretor. O que muda é a propriedade da conversa: o histórico fica na empresa.
Porque a conversa e o cliente vão embora com ele. Quando o corretor sai da imobiliária, o número que o cliente tem salvo continua sendo o dele: a próxima mensagem daquele comprador chega no aparelho de um ex-funcionário, junto com o histórico da negociação, a ficha que foi enviada e o valor que foi discutido. Some a isso o cotidiano — o gestor não consegue conferir o que foi prometido, ninguém retoma o atendimento quando o corretor está de férias, e o mesmo cliente é abordado duas vezes por pessoas diferentes.
Essa é a regra que mais dá vergonha quando falha: cliente recebendo "ainda tem interesse no AP2317?" duas semanas depois de o imóvel ter sido alugado. A régua de follow-up não pode ler uma lista montada no dia anterior — ela precisa consultar a situação do imóvel e do lead no instante do envio, e parar quando a captação sai da carteira, quando há proposta aceita ou quando o corretor marcou o atendimento como encerrado. Vale o mesmo para o imóvel que teve o valor reajustado: melhor não mandar nada do que mandar o valor antigo.
R$ 27 por mês por número conectado, sem cobrança por mensagem: o valor não muda entre 40 e 4.000 mensagens no mês, faixa confortável dentro da cota de 300 mensagens por dia por número — cerca de 9.000 por mês. O teste é de 14 dias sem cartão e só começa a contar na primeira conexão — dá para criar a conta, integrar com o CRM com calma e conectar o número quando a integração estiver pronta.
Essa previsibilidade é o que torna o fluxo viável na captação: entre primeira resposta, qualificação, agendamento, dois lembretes e follow-up, um único lead recebe seis mensagens. Com cobrança por mensagem, o custo cresceria junto com o volume de leads até alguém cortar justamente o lembrete que evita a visita perdida. Com várias lojas, é uma conexão por loja, e o seu sistema escolhe de qual número a mensagem sai trocando o header token.
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 num sábado de plantão, 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 alguém conferir essa lista todo dia. Lembrete de visita que não saiu precisa virar tarefa, não silêncio.
Funciona sempre que o CRM conseguir fazer uma chamada HTTP ou expor os dados de alguma forma. Se ele tem área de integrações ou webhooks de saída, chama a API direto quando o lead entra e quando a visita é agendada. Se é fechado, leia os dados por fora — relatório, banco, exportação — e dispare com uma rotina ou uma ferramenta de automação no meio.
Continua dando. Uma rotina lê a caixa de entrada da captação, extrai telefone, nome e código do anúncio da mensagem do portal e chama /chat/send/text. Não é o caminho mais elegante, mas é o mais comum, e resolve o essencial: a mensagem sai em segundos em vez de sair quando alguém abre o e-mail.
Serve, e é onde a automação rende mais: no sábado a equipe está reduzida e os leads não param de chegar. A primeira resposta e a qualificação continuam saindo, e o que precisa de gente fica na fila do plantonista com o código do imóvel e o resumo do que a pessoa respondeu.
Resolva no seu sistema, não na mensagem. Como todo evento chega por webhook com o telefone e o identificador do lead, o CRM consegue verificar se aquele contato já tem atendimento aberto antes de criar outro e manter o corretor original. Com um número institucional isso é visível; com celular pessoal de cada corretor, ninguém descobre a duplicidade.
R$ 27 por mês por número conectado, sem cobrança por mensagem, com cota de 300 mensagens por dia para cada número conectado — cerca de 9.000 por mês. Esse teto existe para o número da imobiliária não ser lido como disparador em massa pelo WhatsApp. O teste é de 14 dias sem cartão e só começa a contar quando você conecta o primeiro número.
Pode — em qualquer API, inclusive na oficial da Meta. O risco não é eliminável, é gerenciável: fale com quem pediu contato, não transforme a carteira antiga em lista de disparo, mantenha volume compatível com o tamanho da operação e pare de enviar para quem pediu para sair. O que dispara bloqueio é mensagem não solicitada em massa, não o uso de API.
Dá, com POST /chat/send/document: o arquivo vai em base64, com um nome que se explica sozinho na conversa e uma legenda curta. São 13 formas de envio no total — texto, imagem, áudio, vídeo, documento, localização, lista, botões e outras —, então também é possível mandar foto e ponto de encontro quando a política da imobiliária permitir.
Se o atendimento acontece no número institucional, nada: o histórico continua na imobiliária e outro corretor assume a conversa onde ela parou. Basta retirar o aparelho dele dos aparelhos conectados. Se o atendimento acontecia no celular pessoal, a conversa, o cliente e o histórico da negociação saem com ele — e a imobiliária não tem como recuperar.
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 responda o próximo lead em segundos.