Quase todo resultado de integrar WhatsApp com sistema de gestão te manda o mesmo desenho: n8n no meio, webhook da Cloud API de um lado, HTTP Request no prontuário do outro. Dá pra montar. Também dá pro agente, no próprio chat, consultar a agenda da clínica pela API, quando ela existe, sem o orquestrador no caminho.
O que é WhatsApp e sistema de gestão da clínica
WhatsApp e sistema de gestão da clínica é o paciente pedindo horário no chat e o agente consultando o software que a recepção já usa (agenda, paciente, convênio), não só o Google Calendar. Na Zaia isso é o agente no canal mais a tool HTTP Request: GET e POST na API REST do sistema, com a regra na Knowledge e ticket no CRM se a vaga ou o caso pedirem gente.
Não é um conector nativo de iClinic, Feegow, Doctoralia ou ClinPlus. Não é prontuário eletrônico. Se o sistema não tem API, o agente não inventa a ficha. Usa Google Calendar ou abre atendimento.
Middleware n8n vs HTTP Request no agente
O tema não falta conteúdo. Falta o tutorial que não assume orquestrador, nem um vertical de clínica que a Zaia não é.
| n8n + Cloud API + HTTP no HIS | SaaS vertical de clínica | Agente + HTTP Request (Zaia) | |
|---|---|---|---|
| Quem conversa | O nó do modelo no fluxo | O bot do software da clínica | O agente do workspace |
| Onde mora a agenda | O HTTP do workflow | Agenda e prontuário daquela marca | API REST via HTTP Request, se existir |
| Sem API no sistema | Planilha no meio, ou para | Só aquele vertical | Calendar MCP, ou ticket |
| Humano no loop | Slack ou Chatwoot, se você colou | Fila do próprio SaaS | CRM nativo: ticket, takeover, History |
| Quando quebra | Editar o fluxo é editar a produção | Conta nova no vertical | Draft → teste → publicar → rollback |
| Cliente novo | Cópia do webhook, do token e do HTTP | Outra conta no vertical | Workspace, o mesmo padrão de agente, outra credencial |
O caminho n8n funciona para uma clínica só, num fim de semana. O teto é o de criar agente de IA para WhatsApp com n8n: cada cliente novo é uma cópia, o Bearer mora solto, e não há versão para voltar atrás. O vertical resolve quem já vive naquele prontuário. Não copie “40% menos falta” nem “3x mais agendamento”. Isso é claim de concorrente, não dado da Zaia.
O irmão deste texto é agendamento de consultas no WhatsApp. Lá a agenda é o Google Calendar. Aqui a recepção já marca no sistema da clínica. Os dois jobs se parecem. A fonte da vaga muda.
O que isso não é: integração FHIR, escrita no PEP, orientação médica, resultado de exame no fio. A LGPD no atendimento com IA continua valendo: o HTTP leva dado pessoal. Token na tool, papéis no workspace, History auditável. Sem API documentada, não há o que ligar.
O job concreto: a vaga está no sistema, não no Calendar
Ninguém acorda pensando “preciso de uma HTTP Request Tool”. O pedido é este:
O paciente manda “tem horário na quinta com a Dra. Ana?” no WhatsApp. A recepção não usa Google Agenda. Usa o sistema da clínica. Sem a consulta na API, o agente inventa a vaga ou manda a pessoa esperar o dia seguinte.
É o job da tabela de nichos: clínicas médicas, odonto, estética. A agência já atende essa base. O Calendar nativo resolve quem vive no Google. Este artigo é o outro caso.
Três saídas honestas. Nenhuma promete prontuário, nem “substitui a recepção”:
- Cabe e a API responde. O agente pede o mínimo (nome, telefone, profissional). HTTP Request busca disponibilidade. Oferece duas ou três vagas. Se a regra deixar, POST cria o agendamento. Table guarda o estágio: marcado.
- Cabe e pede gente. API fora do ar, convênio que a Knowledge não cobre, encaixe, “é urgente”. Abre ticket. A recepção vê o History e marca no sistema com a pessoa na frente.
- Não cabe. Pedido de diagnóstico, pedido para ler o prontuário inteiro, sistema sem API. Recusa clara. Sem REST, volte ao Calendar ou ao humano.
A regra mora na Knowledge: o que a API pode ler, o que pode gravar, o que nunca sai sem humano. Uma tool por ação. GET de vaga não é POST de consulta.
O agente não substitui 100% da recepção. Dado clínico, valor fora da tabela, paciente irritado: handoff.
Como montar o agente que consulta o sistema da clínica
- Descreva o caso em português. “Secretária: no WhatsApp, se a pessoa pedir horário, consulta a disponibilidade na API da clínica. Se a API falhar ou o caso for encaixe, abre atendimento. Não dá conselho médico.” O Vibe Agent monta a configuração inicial.
- Confirme que o sistema tem API REST. Peça o exemplo de
curl(ClinPlus, por exemplo, publica docs para bot). Semcurl, sem OpenAPI, não há o que importar. Aí o caminho é Calendar ou ticket. - Crie a tool HTTP Request. Cole o
curlno assistente da tool. Uma tool para buscar vaga (GET). Outra, se a API e a clínica deixarem, para criar o agendamento (POST). Descrição em linguagem natural: quando usar, o que nunca chamar. - Properties obrigatórias: data, profissional, telefone. O agente pergunta o que faltar antes de disparar. Não grave segredo no prompt. Header
Authorizationna tool, não no chat. - Coloque o que a API não cobre na Knowledge: convênio, duração, o que levar, o que recusar. A API devolve horário. A base devolve o ofício.
- Publique no WhatsApp (Official ou Waha). Teste no chat interno da tool antes de ir ao número. Widget é porta extra.
- Ligue criação de ticket e Attendants. Timeout, 401, “é urgente”, pedido de exame: a fila aparece com o History. Versionar. Rollback se o agente começar a gravar consulta errada ou a ler campo que a clínica não autorizou.
Não trate Workflows como o motor estável desta chamada. Workflows na Zaia são beta. O caminho shipped é agente + HTTP Request + Knowledge + ticket.
Não prometa conector nativo de iClinic, Feegow, Doctoralia ou ClinPlus, sincronização bidirecional com o PEP, resultado de exame no WhatsApp nem “o agente lê o prontuário”. O que está shipped é a tool HTTP Request no agente publicado, para API REST que a clínica já tenha.
Quando isso vira oferta pra agência
Agência que já fez o site da clínica sente o teto: o horário continua no sistema da recepção. O cliente final reconhece valor quando a quinta-feira que a API devolve entra no fio, não quando recebe um “vou verificar de manhã”.
Empacotar “WhatsApp que consulta o sistema de gestão” pede canal + HTTP Request + regra na base, não um n8n por clínica. Só venda isso se a API existir. Sem API, venda o agendamento no Calendar. Exemplo de precificação pro cliente final: agentes que valem a partir de R$1.500/mês. O piso da plataforma é a partir de R$150. O roteiro de como vender isso pra base que a agência já tem está no Programa de Aceleração.
Perguntas frequentes
O agente de IA consulta o sistema de gestão no WhatsApp?
Sim, quando o sistema tem API REST. Na Zaia isso é a tool HTTP Request no agente publicado, com Knowledge e ticket no CRM. Sem API, o caminho é Google Calendar ou atendimento humano.
Preciso de n8n para ligar o WhatsApp no sistema da clínica?
Não. Na Zaia o agente chama a API direto pela HTTP Request. n8n com webhook e HTTP continua válido. Não é requisito.
A Zaia conecta iClinic, Feegow ou Doctoralia nativamente?
Não. Não há MCP desses sistemas. Se a clínica tiver API documentada, você configura a HTTP Request. Se não tiver, não invente a ficha.
O agente lê e escreve no prontuário?
Não neste desenho. O job é disponibilidade e, se a API e a regra deixarem, criar o agendamento. Dado clínico, diagnóstico e PEP ficam de fora. Caso sensível abre ticket.
Como começar
WhatsApp e sistema de gestão moram na API da clínica, não no fluxo colado: Vibe Agent pra criar em português, número no ar, HTTP Request com o curl da clínica, regra na Knowledge, ticket quando a API falhar ou o caso pedir gente. Descreva a secretária, teste o GET no chat interno, mande um “tem horário na quinta?” de teste.
Começar agora. 7 dias de trial. Depois a partir de R$150.