Ninsaúde
O Ninsaúde é o NicoApp de integração com o Ninsaúde, sistema de gestão para clínicas de saúde (prontuário eletrônico, agenda e pacientes). Com ele, seu bot busca, cadastra e atuali
Nota
Disponível na aba de NicoApps. Base da integração: API REST oficial da Ninsaúde (api.ninsaude.com/v1), autenticada via Bearer Token enviado no cabeçalho
Authorization de cada requisição.Como obter as credenciais da API
Na instalação do NicoApp, você informa um único campo: o Token de Acesso (Bearer), usado em todas as chamadas como Authorization: Bearer <token>.
A própria Ninsaúde documenta a autenticação da sua plataforma de desenvolvimento (Ninsaúde Toro) como segue:
- O padrão é OAuth2, com dois tokens: um Access Token, usado em todos os cabeçalhos de requisição, com validade de 15 minutos (funciona como uma sessão); e um Refresh Token, sem validade definida, usado apenas para obter novos Access Tokens — ele substitui o compartilhamento de usuário/senha com o app.
- A API segue o padrão RESTful, com "milhares de rotas disponíveis", documentadas em uma coleção pública no Postman ("Ninsaúde Clinic").
Atenção
A Ninsaúde não publica um guia de autoatendimento para gerar essas credenciais. Solicite ao suporte ou ao time comercial Ninsaúde o token/credencial de integração para uso neste miniapp.
Recomendação: entre em contato com o suporte ou o time comercial da Ninsaúde (pelo painel da clínica ou pelos canais de atendimento) e peça a emissão do Bearer Token de integração para a API. Ao configurar, confirme com eles se esse token expira (e precisa ser renovado periodicamente, como o Access Token de 15 min do fluxo OAuth2 padrão) ou se é um token de integração de longa duração — isso muda a forma como você deve reinstalá-lo/atualizá-lo no app.
Limitações
Atenção
Limite de requisições e planos com acesso à API não são divulgados publicamente pela Ninsaúde. Confirme com o suporte Ninsaúde antes de dimensionar fluxos de alto volume.
- Validade do token: se a credencial seguir o padrão OAuth2 descrito pela Ninsaúde, o Access Token dura apenas 15 minutos — o token usado neste app precisa ser confirmado com o suporte quanto à sua validade e à necessidade (ou não) de renovação periódica.
- Plano necessário: não documentado publicamente. Trate como uma pergunta obrigatória ao ativar a integração com o cliente.
O que o miniapp faz
Pacientes
Ação
Endpoint
O que faz
Entradas principais
Saídas
Criar Paciente
POST /cadastro_paciente
Cadastra um novo paciente
Nome (obrigatório); Nome Social, Nascimento, Sexo, Estado Civil, Raça/Cor, CPF, CNS, Nome da Mãe/Pai, E-mail, Profissão, Celular, Telefones, Endereço (CEP/Cidade/Bairro/Logradouro), Convênio/Plano/Carteirinha, Bandeira, Observação
ID do Paciente
Atualizar Paciente
PUT /cadastro_paciente/{id}
Atualiza os dados de um paciente existente
ID do Paciente (obrigatório) + os mesmos campos de Criar Paciente — só os campos preenchidos são enviados no PUT
ID do Paciente
Buscar Paciente
GET /cadastro_paciente/listar
Busca um paciente por CPF, e-mail ou celular (tenta nessa ordem)
CPF, E-mail ou Celular (ao menos um)
Todos os dados do paciente (nome, contatos, endereço, convênio…) e o ID; erros dedicados para "Paciente não encontrado" e "Múltiplos pacientes encontrados"
Remover Paciente
DELETE /cadastro_paciente/{id}
Exclui o cadastro de um paciente
ID do Paciente
Confirmação/Erro
Agenda
Ação
Endpoint
O que faz
Entradas principais
Saídas
Horários Disponíveis
GET /atendimento_agenda/listar/horario/disponivel/profissional/{id}/dataInicial/{}/dataFinal/{}
Lista horários livres de um profissional
Profissional (obrigatório); Data Inicial (padrão: hoje) e Data Final (padrão: Data Inicial + 3 dias) — preenchidas automaticamente se vierem vazias
Lista de horários disponíveis
Agendar Consulta
POST /atendimento_agenda
Cria um novo agendamento
Unidade, Profissional, Data, Hora Inicial, Paciente, Status, Serviço, Especialidade, Sala; Hora Final é opcional
ID do Agendamento
Reagendar Consulta (sub-fluxo interno: "Agendar Consulta #1")
POST /atendimento_agenda/reagendar/agendamento/{id}
Move um agendamento existente para nova data/hora
ID do Agendamento (obrigatório), Nova Data, Nova Hora Inicial; Nova Hora Final é opcional
ID do Agendamento
Excluir Agendamento
DELETE /atendimento_agenda/{id}
Cancela/exclui um agendamento
ID do Agendamento
Confirmação/Erro
Editar Status Agendamento
PUT /atendimento_agenda/alterar/status/agendamento/{id}
Altera o status de um agendamento (ex.: presença/falta/cancelamento)
ID do Agendamento, Status
Confirmação/Erro
Comunicação interna
Ação
Endpoint
O que faz
Entradas principais
Saídas
Mandar Mensagem Interna
POST /geral_batepapo
Envia uma mensagem no bate-papo interno da Ninsaúde para um usuário/atendente
Usuário Destino (ID), Mensagem
Confirmação/Erro
Dicas e observações
- "Agendar Consulta" x "Agendar Consulta #1": apesar do nome parecido, não são duplicadas — Agendar Consulta cria um agendamento novo (
POST /atendimento_agenda) e Agendar Consulta #1 na verdade reagenda um agendamento existente (POST /atendimento_agenda/reagendar/agendamento/{id}). Nesta documentação ela foi chamada de Reagendar Consulta para deixar o propósito claro.
Nota
Revisão futura sugerida: renomear o sub-fluxo "Agendar Consulta #1" no editor do app para "Reagendar Consulta" (ou similar), evitando a confusão com a ação "Agendar Consulta".
- Cálculo automático de Hora Final: em Agendar Consulta e em Reagendar Consulta, se a Hora Final não for informada, o app busca a duração padrão do Serviço escolhido (
GET /cadastro_servico/{id}→duracaoPadrao) e calcula Hora Final = Hora Inicial + duração automaticamente — não é preciso informar os dois horários manualmente. - IDs encadeados: o ID do Paciente sai de Criar/Buscar Paciente e entra em Atualizar, Remover e Agendar Consulta. O ID do Agendamento sai de Agendar Consulta e entra em Reagendar Consulta, Excluir Agendamento e Editar Status Agendamento.
- Formatos de data/hora: datas em
AAAA-MM-DD(ex.: 2026-08-01); horários emHH:MM:SS(ex.: 17:00:00). - Buscar Paciente: a ação tenta CPF, depois e-mail, depois celular, nessa ordem, até achar exatamente um paciente — se não achar nenhum, o erro é "Paciente não encontrado"; se achar mais de um, "Múltiplos pacientes encontrados" (peça um dado mais específico ao usuário para refinar a busca).
- Mensagem Interna: o texto enviado é higienizado antes do envio — quebras de linha e tabs viram espaço, aspas simples viram crase e aspas duplas viram aspas curvas, evitando quebrar o JSON da requisição.
- Tratamento de erros: toda ação devolve o erro real da Ninsaúde (campo
errorda resposta) quando a chamada falha — use o caminho de erro do bloco para tratar no fluxo (ex.: token inválido/expirado, horário indisponível, campo obrigatório faltando).