Rapidoc Telemedicina · Developers

API Rapidoc Telemedicina

TEMA v2 — guia de integração para parceiros. Administre as vidas cobertas pelo contrato: planos, empresas, beneficiários, fila de pronto atendimento, agendamento e histórico. Os produtos VitalScan, VitalCheck AI e BabyCare têm abas próprias.

Versão TEMA v2Sandbox https://sandbox.rapidoc.techLimite 30 req/min por IP

Visão geral

A API TEMA v2 permite ao parceiro administrar as vidas cobertas pelo seu contrato com a Rapidoc: consultar os planos contratados, organizar as vidas em empresas, cadastrar e atualizar beneficiários (titulares e dependentes), abrir atendimentos na fila, agendar consultas e acompanhar o histórico de atendimentos.

Todos os endpoints deste documento usam o prefixo /tema/api e a versão 2 da API, selecionada pelo Content-Type.

Duas regras que causam perda de dados

Os planos vão sempre completos no beneficiário. O array plans substitui a lista inteira. No POST, o dependente não envia plans e herda os do titular; no PUT, toda vida envia plans, inclusive o dependente. Regra 1.
Dependente exige holder em todo update. Sem o holder, a API entende que a vida deixou de ser dependente e apaga o vínculo com o titular. Regra 2.

Antes de integrar, leia as boas práticas

A API aceita até 30 requisições por minuto por IP. A aba Boas práticas mostra o que salvar na sua base e como montar cada jornada com o mínimo de chamadas.

Ambientes e autenticação

Ambiente	Base URL
Sandbox	`https://sandbox.rapidoc.tech`
Produção	`https://api.rapidoc.tech`

Desenvolva e teste sempre no sandbox

Toda a implementação, os testes e a homologação acontecem no sandbox.

Headers obrigatórios em todas as chamadas, inclusive nos GET:

Header	Valor	Observação
`Authorization`	`Bearer <token>`	Token do parceiro, fornecido pela Rapidoc
`clientId`	`<uuid-do-cliente>`	Identifica o cliente e define os planos visíveis
`Content-Type`	`application/vnd.rapidoc.tema-v2+json`	Seleciona a versão 2 da API

Erro de autenticação volta com HTTP 200

Quando um header de autenticação falta ou é inválido, a API responde 200 com success: false e o motivo em message. Confira o success do corpo, não só o status HTTP.

resposta · token inválido

{ "success": false, "message": "token inválido para este cliente." }

Situação	message
`Authorization` ausente, vazio ou sem o prefixo `Bearer`	`Authorization inválido.`
Token que não pertence ao `clientId` enviado	`token inválido para este cliente.`
`clientId` ausente	`clientId não informado.`
`clientId` inexistente	`clientId inválido.`

Códigos usados na API

Código	Onde aparece	Significado
`S`	`plans[].paymentType`	Recorrente — assinatura mensal da vida
`A`	`plans[].paymentType`	Avulso — cobrado por atendimento realizado
`L`	`paymentType` do `GET /plans`	Livre: o parceiro escolhe entre `S` e `A` ao vincular
`G`	`plan.serviceType`	Generalista 24/7
`GS`	`plan.serviceType`	Generalista 24/7 + Especialidades
`P`	`plan.serviceType`	Psicologia

Esses códigos pertencem ao plano, não ao beneficiário — veja o que saiu do payload.

Ordem de integração

Autenticar — token e clientId fornecidos pela Rapidoc.
Ler os planos — GET /tema/api/plans devolve os planos contratados e o paymentType de cada um.
Criar a empresa (opcional) — POST /tema/api/companies devolve o uuid enviado em company.uuid. O cadastro de beneficiários não depende desta etapa.
Cadastrar os beneficiários — POST /tema/api/beneficiaries, com o array plans completo nos titulares e o holder nos dependentes, até 10 vidas por requisição.
Atender — fila de pronto atendimento, consultas agendadas, encaminhamentos e histórico de uso.

Planos

GET/tema/api/plans

Retorna os planos contratados pelo cliente do header clientId, com as especialidades cobertas por cada um. Cada item traz o paymentType contratado e, dentro de plan, os dados do plano. É a origem do par paymentType + plan.uuid usado em plans[] do beneficiário — nunca fixe esses UUIDs no código do parceiro.

curl

curl --location '{{BASE_URL}}/tema/api/plans' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Resposta 200 OK:

json

[
  {
    "paymentType": "L",
    "plan": {
      "uuid": "UUID_DO_PLANO_BASICO",
      "name": "Básico",
      "description": "Plano Básico (Generalista 24/7)",
      "serviceType": "G",
      "specialties": []
    }
  },
  {
    "paymentType": "S",
    "plan": {
      "uuid": "UUID_DO_PLANO_PREMIUM",
      "name": "Premium",
      "description": "Plano Premium (Generalista 24/7 + Especialidades)",
      "serviceType": "GS",
      "specialties": [
        { "name": "Pediatria", "uuid": "UUID_DA_ESPECIALIDADE_1", "cbo": "225124" },
        { "name": "Cardiologia", "uuid": "UUID_DA_ESPECIALIDADE_2", "cbo": "225120" }
      ]
    }
  },
  {
    "paymentType": "S",
    "plan": {
      "uuid": "UUID_DO_PLANO_PSICOLOGIA",
      "name": "Psicologia",
      "description": "Plano de Psicologia",
      "serviceType": "P",
      "specialties": [
        { "name": "Psicologia", "uuid": "UUID_DA_ESPECIALIDADE_3", "cbo": "251510" }
      ]
    }
  }
]

Importante

O paymentType de cada item de plans[] deve ser idêntico ao que veio no GET /plans para aquele plano. A única exceção é o plano com paymentType igual a L, em que o parceiro escolhe entre S e A no momento do vínculo.

Empresas

O beneficiário pode ser vinculado a uma empresa do cliente por company.uuid — o vínculo é opcional e não é pré-requisito para o cadastro. Inativar a empresa inativa em cascata as vidas vinculadas a ela: cada beneficiário ativo da empresa é inativado com a mesma data/hora — o mesmo efeito de um DELETE /beneficiaries/{uuid} direto (cancela as consultas SCHEDULED e os encaminhamentos em aberto de cada um). Reativar a empresa reativa automaticamente apenas os beneficiários que foram inativados junto, no mesmo momento; quem foi inativado por outro motivo continua inativo.

Endpoint	O que faz	Resposta
`GET /tema/api/companies`	Lista as empresas do cliente	`200`
`POST /tema/api/companies`	Cria a empresa (body com `name`)	`201` com o `uuid`
`PUT /tema/api/companies/{uuid}`	Atualiza o nome e o `hasNr1`	`204` — `409` ao ligar o `hasNr1` sem o produto
`PUT /tema/api/companies/{uuid}/inactivate`	Inativa a empresa em cascata (vidas vinculadas junto)	`200` com `inactivatedAt`
`PUT /tema/api/companies/{uuid}/reactivate`	Reativa a empresa em cascata (mesmas vidas)	`200`

Campo hasNr1

hasNr1 diz se a empresa tem o produto NR1 habilitado. Ele só vem na resposta das empresas em que o campo já foi definido — trate como opcional e ignore quando não vier.

Para ligar o NR1, envie hasNr1: true no PUT /companies/{uuid}. Isso só é aceito se o cliente tiver o produto NR1 vinculado e ativo; caso contrário a API responde 409.

resposta 409 · cliente sem o produto

{ "message": "A empresa só pode habilitar o NR1 se o cliente tiver o produto NR1 ativo." }

Exemplos de chamada

Uma requisição por endpoint; todas com os três headers.

Listar empresas — GET /tema/api/companies

curl · GET /companies

curl --location '{{BASE_URL}}/tema/api/companies' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

json · resposta do GET

[
  {
    "uuid": "UUID_DA_EMPRESA",
    "name": "Empresa Exemplo Ltda",
    "client": { "name": "NOME_DO_CLIENTE", "uuid": "UUID_DO_CLIENTE" },
    "isActive": true,
    "createdBy": "UUID_DO_USUARIO",
    "updatedBy": "UUID_DO_USUARIO",
    "createdAt": "21/08/2026 10:53:44",
    "updatedAt": "21/08/2026 10:53:44"
  }
]

Criar empresa — POST /tema/api/companies

curl · POST /companies

curl --location '{{BASE_URL}}/tema/api/companies' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json' \
  --data '{ "name": "Empresa Exemplo Ltda" }'

json · resposta do POST

{
  "uuid": "UUID_DA_EMPRESA",
  "name": "Empresa Exemplo Ltda",
  "client": { "name": "NOME_DO_CLIENTE", "uuid": "UUID_DO_CLIENTE" },
  "isActive": true,
  "createdBy": "UUID_DO_USUARIO",
  "updatedBy": "UUID_DO_USUARIO",
  "createdAt": "18/05/2026 09:45:05",
  "updatedAt": "18/05/2026 09:45:05"
}

Atualizar nome da empresa — PUT /tema/api/companies/{uuid}

curl · PUT /companies/{uuid}

curl --location --request PUT '{{BASE_URL}}/tema/api/companies/UUID_DA_EMPRESA' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json' \
  --data '{ "name": "Novo Nome Ltda" }'

Inativar empresa — PUT /tema/api/companies/{uuid}/inactivate

curl · PUT /companies/{uuid}/inactivate

curl --location --request PUT '{{BASE_URL}}/tema/api/companies/UUID_DA_EMPRESA/inactivate' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Reativar empresa — PUT /tema/api/companies/{uuid}/reactivate

curl · PUT /companies/{uuid}/reactivate

curl --location --request PUT '{{BASE_URL}}/tema/api/companies/UUID_DA_EMPRESA/reactivate' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Tipos de documento

GET/tema/api/document-types

Lista os tipos de documento aceitos no cadastro de uma vida, de acordo com o país do cliente do header clientId. Um cliente brasileiro recebe apenas o CPF; clientes de outros países recebem os documentos daquele país. Consulte antes do cadastro e use os valores de cada item no payload do beneficiário:

countryCode vai em country;
type vai em documentType;
mask é o formato esperado em documentNumber (# = dígito, A = letra). A máscara define o tamanho exigido: o número precisa ter tantos caracteres quantos forem os # e A da máscara. Máscara vazia não valida tamanho.

curl

curl --location '{{BASE_URL}}/tema/api/document-types' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

json · cliente do Brasil

[
  { "countryCode": "BRA", "type": "CPF", "label": "CPF", "mask": "###.###.###-##" }
]

json · cliente de outro país (exemplo: Angola)

[
  { "countryCode": "AGO", "type": "BI", "label": "Bilhete de Identidade", "mask": "#########AA###" },
  { "countryCode": "AGO", "type": "PASSPORT", "label": "Passaporte", "mask": "" }
]

Beneficiários

Regra 1 — planos sempre completos

O array plans substitui integralmente a lista de planos da vida. Ao processar um POST ou um PUT, a API remove os vínculos de plano existentes e recria a lista a partir do que chegou no payload.

No POST, dependente não leva plans: herda os planos do titular indicado em holder (Regra 2). Já no PUT, toda vida leva plans, inclusive o dependente — ver PUT /beneficiaries/{uuid}.

Consequências práticas:

Enviar apenas o plano novo remove todos os outros.
Omitir plans no PUT, ou mandar plans: [], faz a API recusar a requisição com 400 e Invalid payment type. Accept: 'S' and 'A' — nada é alterado.
Não existe atualização parcial de planos — monte a lista inteira a cada envio, repetindo inclusive os planos que não mudaram.

Faça

Ler o GET /plans e montar a lista completa a cada envio
Repetir os planos que já existiam, mesmo sem alteração
Usar o paymentType exatamente como veio do GET /plans
Deixar a cobrança em plans[].paymentType

Não faça

Enviar só o plano que está sendo contratado agora
Omitir plans no PUT — a requisição inteira é recusada
Supor que a API faz merge dos planos — ela substitui
Enviar paymentType ou serviceType na raiz do beneficiário

paymentType e serviceType saíram do payload do beneficiário

Até a versão anterior, paymentType e serviceType ficavam na raiz do beneficiário e descreviam a cobrança e o serviço da vida inteira. Na v2 essa informação vem dos planos:

plans[].paymentType define a cobrança de cada plano vinculado;
plan.serviceType descreve o serviço daquele plano (devolvido pelo GET /plans).

Os dois campos continuam existindo na raiz do beneficiário apenas por compatibilidade com integrações antigas — não os envie no POST nem no PUT. Eles seguem aparecendo nas respostas, refletindo o que a API derivou dos planos da vida.

Na prática: um beneficiário com plano Premium recorrente e Psicologia avulso não tem um paymentType único que descreva os dois; quem carrega essa informação é cada item de plans[].

Regra 2 — holder em todo update de dependente

holder é o CPF do titular (11 dígitos, sem pontuação). Ele é o que define que a vida é dependente de outra.

No PUT, o campo é interpretado assim:

Situação	Resultado
`holder` com 11 dígitos válidos	Vínculo mantido/criado; o dependente herda os planos do titular
`holder` igual ao CPF do próprio beneficiário	Recusado: a vida não pode ser dependente dela mesma
`holder` de CPF não cadastrado no mesmo cliente	Recusado: o titular precisa existir
`holder` que já é dependente de outra vida	Recusado: não há dependência em dois níveis
Vida que já possui dependentes recebendo um `holder`	Recusado: transfira os dependentes para outro titular antes
`holder` ausente, vazio ou `null`	Vínculo apagado: a vida passa a valer como titular independente

Efeito destrutivo silencioso

Uma atualização trivial — trocar o telefone de um dependente — feita sem o campo holder desfaz a dependência. Guarde o vínculo titular/dependente do lado do parceiro e repita o holder em todo PUT de dependente.

Quando o holder é enviado, a API replica os planos do titular no dependente. Para promover um dependente a titular, envie o PUT sem holder e com o array plans que a vida passa a ter.

POST/tema/api/beneficiaries

Adiciona um ou mais beneficiários (máximo de 10 por requisição). Devolve o uuid de cada vida, usado em todas as demais operações.

Campo	Tipo	Regra
`name`	string	Obrigatório. Mínimo de 5 caracteres
`cpf`	string	11 dígitos, sem pontuação. Único por beneficiário
`birthday`	string	Obrigatório. Formato `yyyy-MM-dd`
`phone`	string	11 dígitos no Brasil, sem o DDI; 9 em Angola e Portugal; 10 nos EUA
`email`	string	Único por beneficiário
`zipCode`, `address`, `city`, `state`	string	Endereço; `state` com 2 caracteres (UF)
`country`	string	Código do país (`BRA`, `AGO`, `PRT`, `USA`)
`documentType`	string	Condicional. Obrigatório para estrangeiros (ex.: `BI`, `PASSPORT`)
`documentNumber`	string	Condicional. Número do documento estrangeiro
`company.uuid`	UUID	Opcional. Empresa a que a vida pertence
`holder`	string	CPF do titular, quando a vida é dependente
`plans`	array	Obrigatório para titular. Lista completa de planos — ver Regra 1. Dependente não envia: herda do titular
`plans[].paymentType`	string	`S` ou `A`, conforme o `GET /plans`
`plans[].plan.uuid`	UUID	UUID do plano

Beneficiário brasileiro, titular:

curl · POST /beneficiaries

curl --location '{{BASE_URL}}/tema/api/beneficiaries' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json' \
  --data '[
    {
      "name": "João Silva",
      "cpf": "34088529014",
      "birthday": "1984-12-12",
      "phone": "51993949830",
      "email": "joao@exemplo.com",
      "zipCode": "91060000",
      "address": "Rua Teste, 500",
      "city": "Porto Alegre",
      "state": "RS",
      "company": { "uuid": "UUID_DA_EMPRESA" },
      "plans": [
        { "paymentType": "S", "plan": { "uuid": "UUID_DO_PLANO_PREMIUM" } },
        { "paymentType": "A", "plan": { "uuid": "UUID_DO_PLANO_PSICOLOGIA" } }
      ]
    }
  ]'

Dependente — mesma requisição, com o holder no lugar de plans:

json

[
  {
    "name": "Maria Silva",
    "cpf": "53482921091",
    "birthday": "2010-03-22",
    "phone": "51993949830",
    "company": { "uuid": "UUID_DA_EMPRESA" },
    "holder": "34088529014"
  }
]

Beneficiário estrangeiro — sem CPF, com documento do país:

json

[
  {
    "name": "Adilson Chiminho Pascoal",
    "birthday": "1990-01-01",
    "phone": "933221167",
    "country": "AGO",
    "documentType": "BI",
    "documentNumber": "NUMERO_DO_DOCUMENTO",
    "company": { "uuid": "UUID_DA_EMPRESA" },
    "plans": [
      { "paymentType": "S", "plan": { "uuid": "UUID_DO_PLANO_PREMIUM" } }
    ]
  }
]

Resposta 200 OK — a API devolve o que foi enviado, mais uuid, documentType, documentNumber, clientId e parameters:

json

{
  "success": true,
  "message": "Processamento concluido com sucesso.",
  "beneficiaries": [
    {
      "name": "João Silva",
      "uuid": "UUID_DO_BENEFICIARIO",
      "cpf": "34088529014",
      "birthday": "1984-12-12",
      "documentType": "CPF",
      "documentNumber": "34088529014",
      "clientId": "UUID_DO_CLIENTE",
      "plans": [
        { "paymentType": "S", "plan": { "uuid": "UUID_DO_PLANO_PREMIUM" } }
      ],
      "parameters": []
    }
  ]
}

O birthday volta como foi enviado (yyyy-MM-dd). Nas consultas, a mesma data aparece em dd/MM/yyyy.
O phone é gravado com o DDI do país: 11999999999 é consultado depois como 5511999999999.
parameters é de uso interno e vem vazio — ignore.

Erros de cadastro

A validação também responde 200: confira o success. A message começa com Inconsistências: e o número entre colchetes é a posição da vida no array enviado, começando em 1.

resposta · telefone com DDI

{
  "success": false,
  "message": "Inconsistências: [1] - Telefone inválido. Deve ter 11 dígitos se country não informado.",
  "beneficiaries": []
}

resposta · CPF repetido

{ "success": false, "message": "CPF já cadastrado.;", "beneficiaries": [] }

PUT/tema/api/beneficiaries/{uuid}

Atualiza dados cadastrais, planos e vínculo de dependência de uma vida existente. Os campos seguem as mesmas regras do cadastro, com três diferenças:

cpf não é alterável. Um PUT com CPF diferente do cadastrado é recusado.
email só vai no payload quando for realmente trocado. A validação de e-mail duplicado não desconsidera o próprio beneficiário: reenviar o e-mail que já está gravado é recusado com Email address already in use. Para manter o e-mail atual, omita o campo.
Todo PUT leva plans. Diferente do POST, aqui o dependente também envia a lista de planos — sem ela a API responde 400 com Invalid payment type. Accept: 'S' and 'A'. O dependente leva plans e holder.

Vale para qualquer campo: o PUT só altera o que vem no corpo. As exceções são plans, cuja ausência faz a API recusar a requisição, e holder, que apaga o vínculo de dependência quando omitido (Regra 2).

Titular — planos próprios, sem holder:

curl

curl --location --request PUT '{{BASE_URL}}/tema/api/beneficiaries/UUID_DO_BENEFICIARIO' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json' \
  --data '{
    "name": "João Silva",
    "birthday": "1984-12-12",
    "phone": "51993949830",
    "company": { "uuid": "UUID_DA_EMPRESA" },
    "plans": [
      { "paymentType": "S", "plan": { "uuid": "UUID_DO_PLANO_PREMIUM" } },
      { "paymentType": "A", "plan": { "uuid": "UUID_DO_PLANO_PSICOLOGIA" } }
    ]
  }'

Dependente — o holder acompanha toda atualização, junto com plans:

json

{
  "name": "Maria Silva",
  "birthday": "2010-03-22",
  "phone": "51993949830",
  "company": { "uuid": "UUID_DA_EMPRESA" },
  "holder": "34088529014",
  "plans": [
    { "paymentType": "S", "plan": { "uuid": "UUID_DO_PLANO_PREMIUM" } }
  ]
}

Resposta 200 OK com success, message e o objeto beneficiary atualizado. Em caso de erro, 400 com a lista errors, em que cada item traz a descrição do campo recusado.

resposta 400 · plans ausente ou vazio

{ "success": false, "errors": [ { "description": "Invalid payment type. Accept: 'S' and 'A'" } ] }

Combinações de planos proibidas pelo contrato respondem 422, num formato diferente, com a explicação em message:

resposta 422 · planos incompatíveis

{ "message": "Não é aceito adicionar o plano Básico e plano (Premium) ao mesmo tempo." }

GET/tema/api/beneficiaries/{uuid}/request-appointment

Devolve a URL do atendimento imediato com o generalista (fila de pronto atendimento). A URL deve ser aberta em um webview para o beneficiário entrar na fila.

curl

curl --location '{{BASE_URL}}/tema/api/beneficiaries/UUID_DO_BENEFICIARIO/request-appointment' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

json

{
  "success": true,
  "message": "Processamento concluido com sucesso.",
  "url": "https://DOMINIO_DA_FILA/fila/58/UUID_DA_FILA/TOKEN_DE_ACESSO"
}

Abra a url exatamente como veio: o domínio, o caminho e o token são gerados a cada chamada e não devem ser montados nem validados no seu código. Para liberar câmera e microfone na página da fila, siga as boas práticas de câmera e microfone.

Regras:

A vida precisa ter plano com serviço generalista (G, GS, GP ou GSP). Sem isso, a resposta é 422 com a mensagem de plano generalista obrigatório.
O limite de atendimentos de fila configurado para o cliente é verificado a cada chamada: quando estourado, a resposta vem 200 com success: false — sempre confira o success antes de abrir a URL.
A URL é de uso único: gere uma nova a cada atendimento.
Vale também para dependente: ele entra na fila com o plano herdado do titular.
UUID de beneficiário inexistente responde 404 com success: false.

resposta 404 · beneficiário não encontrado

{ "success": false, "message": "Beneficiário não encontrado." }

DELETE/tema/api/beneficiaries/{uuid}

Desliga a vida. A inativação é em cascata:

Os dependentes do titular são inativados junto, com a mesma data de inativação.
Consultas com status SCHEDULED da vida e dos dependentes são canceladas.
Encaminhamentos em aberto são cancelados.
A cobrança é mantida até o último dia do mês corrente.

Inativar um dependente sozinho não afeta o titular; inativar o titular desativa seus dependentes.

curl

curl --location --request DELETE '{{BASE_URL}}/tema/api/beneficiaries/UUID_DO_BENEFICIARIO' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

json · resposta da primeira inativação

{
  "success": true,
  "message": "Processamento concluido com sucesso.",
  "beneficiary": {
    "name": "João Silva",
    "uuid": "UUID_DO_BENEFICIARIO",
    "cpf": "34088529014",
    "isActive": false,
    "createdAt": "2026-09-17 15:30:52",
    "updatedAt": "2026-09-17 15:46:26",
    "inactivatedAt": "2026-09-17 15:46:26",
    "dependents": [
      { "name": "Maria Silva", "uuid": "UUID_DO_DEPENDENTE", "holder": "34088529014", "isActive": false }
    ]
  }
}

inactivatedAt e os dependents já vêm com isActive: false — dá para conferir a cascata na própria resposta.
As datas desta resposta vêm em yyyy-MM-dd HH:mm:ss, e não no dd/MM/yyyy HH:mm:ss das consultas.
Repetir o DELETE numa vida já inativa responde 200 com success: true, mas o beneficiary volta reduzido, só com o uuid.

PUT/tema/api/beneficiaries/{uuid}/reactivate

Religa uma vida inativada, limpando a data de inativação.

Voltam junto apenas os dependentes inativados no mesmo momento que o titular. Quem foi inativado em outra data continua inativo e precisa ser reativado individualmente.
Agendamentos cancelados na inativação não voltam: refaça o agendamento.
Os planos permanecem os que a vida tinha antes da inativação.

curl

curl --location --request PUT '{{BASE_URL}}/tema/api/beneficiaries/UUID_DO_BENEFICIARIO/reactivate' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Resposta 200 OK com o beneficiary completo: isActive volta a true, o inactivatedAt some, os dependents aparecem reativados e os plans continuam os mesmos de antes.

Demais operações de consulta

Endpoint	O que faz
`GET /tema/api/beneficiaries`	Lista as vidas do cliente, com empresa e situação — sem os planos
`GET /tema/api/beneficiaries/{cpf}`	Busca uma vida pelo CPF, com `plans` e `dependents`
`GET /tema/api/beneficiaries/document/{documentNumber}`	Busca uma vida pelo número do documento, com `plans` e sem `dependents`
`GET /tema/api/beneficiaries/{uuid}/appointments`	Consultas agendadas da vida
`GET /tema/api/beneficiaries/{uuid}/medical-referrals`	Encaminhamentos da vida

A resposta vem dentro de um envelope

As consultas de beneficiário respondem com success, message e os dados em beneficiaries (lista) ou beneficiary (busca por CPF ou documento). Quando nada é encontrado, o status continua 200 e o corpo traz success: false com "Beneficiário não encontrado.".

Exemplos de chamada

Uma requisição por endpoint; todas com os três headers.

Listar vidas do cliente

curl · GET /beneficiaries

curl --location '{{BASE_URL}}/tema/api/beneficiaries' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

json · resposta do GET /beneficiaries

{
  "success": true,
  "message": "Processamento concluido com sucesso.",
  "beneficiaries": [
    {
      "name": "João Silva",
      "uuid": "UUID_DO_BENEFICIARIO",
      "cpf": "34088529014",
      "birthday": "15/01/1982",
      "phone": "5511999999999",
      "email": "joao.silva@exemplo.com",
      "zipCode": "01310100",
      "address": "Avenida Paulista",
      "city": "São Paulo",
      "state": "SP",
      "holder": "CPF_DO_TITULAR",
      "documentType": "CPF",
      "documentNumber": "34088529014",
      "isActive": true,
      "createdAt": "07/08/2026 15:51",
      "clientId": "UUID_DO_CLIENTE",
      "company": { "name": "Empresa Exemplo Ltda", "uuid": "UUID_DA_EMPRESA" }
    }
  ]
}

plans não vem nesta lista — use a busca por CPF quando precisar dos planos da vida.
phone, company, holder e o endereço (zipCode, address, city, state) só aparecem quando a vida tem o dado. holder só vem em dependente.
O createdAt desta resposta vem sem os segundos (dd/MM/yyyy HH:mm).

Buscar vida por CPF

curl · GET /beneficiaries/{cpf}

curl --location '{{BASE_URL}}/tema/api/beneficiaries/34088529014' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

json · resposta do GET /beneficiaries/{cpf}

{
  "success": true,
  "message": "Processamento concluido com sucesso.",
  "beneficiary": {
    "name": "João Silva",
    "uuid": "UUID_DO_BENEFICIARIO",
    "cpf": "34088529014",
    "birthday": "15/01/1982",
    "email": "joao.silva@exemplo.com",
    "documentType": "CPF",
    "documentNumber": "34088529014",
    "isActive": true,
    "dependents": [],
    "clientId": "UUID_DO_CLIENTE",
    "company": { "name": "Empresa Exemplo Ltda", "uuid": "UUID_DA_EMPRESA" },
    "plans": [
      {
        "paymentType": "S",
        "plan": {
          "uuid": "UUID_DO_PLANO_BASICO",
          "name": "Básico",
          "description": "Plano Básico (Generalista 24/7)",
          "serviceType": "G",
          "specialties": []
        }
      }
    ]
  }
}

Os planos vêm no mesmo formato do GET /plans: paymentType na raiz do item e os dados do plano em plan. Esta resposta não traz createdAt.

Em um titular com dependentes, dependents traz cada dependente de forma resumida — name, uuid, cpf, birthday, phone, email, holder, isActive, createdAt e clientId. O dependente aninhado não repete plans, documentType nem documentNumber:

json · trecho do titular com dependente

"dependents": [
  {
    "name": "Maria Silva",
    "uuid": "UUID_DO_DEPENDENTE",
    "cpf": "CPF_DO_DEPENDENTE",
    "birthday": "01/01/1995",
    "phone": "5511999999999",
    "email": "maria.silva@exemplo.com",
    "holder": "34088529014",
    "isActive": true,
    "createdAt": "17/08/2026 16:08",
    "clientId": "UUID_DO_CLIENTE"
  }
]

Buscando o dependente pelo CPF dele, a resposta traz holder com o CPF do titular e os plans herdados preenchidos — não vem dependents.

Buscar vida por documento

curl · GET /beneficiaries/document/{documentNumber}

curl --location '{{BASE_URL}}/tema/api/beneficiaries/document/NUMERO_DO_DOCUMENTO' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Vale para qualquer vida, inclusive brasileira: no cadastro com CPF, o documentNumber é o próprio CPF. Envie o número sem pontuação, exatamente como foi cadastrado — com máscara, a API não encontra a vida. A resposta é a mesma da busca por CPF, com plans, mas sem dependents.

Consultas agendadas da vida

curl · GET /beneficiaries/{uuid}/appointments

curl --location '{{BASE_URL}}/tema/api/beneficiaries/UUID_DO_BENEFICIARIO/appointments' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Encaminhamentos da vida

curl · GET /beneficiaries/{uuid}/medical-referrals

curl --location '{{BASE_URL}}/tema/api/beneficiaries/UUID_DO_BENEFICIARIO/medical-referrals' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Encaminhamentos

Encaminhamentos são emitidos pelos médicos durante os atendimentos e são o ponto de partida de parte dos agendamentos: o uuid do encaminhamento vai em beneficiaryMedicalReferralUuid no POST /appointments. Por isso esta seção vem antes do agendamento.

Endpoint	O que faz
`GET /tema/api/beneficiary-medical-referrals`	Todos os encaminhamentos do cliente
`GET /tema/api/beneficiaries/{uuid}/medical-referrals`	Encaminhamentos de uma vida

Campo	Descrição
`uuid`	Usado em `beneficiaryMedicalReferralUuid` no agendamento
`beneficiary`	Vida encaminhada: `name`, `uuid`, `cpf`, `email`, `birth`, `phone`, `isActive` e `client`. A data de nascimento vem em `birth`, e não em `birthday`
`specialty`	Especialidade do encaminhamento, com `name`, `uuid` e `cbo`
`status`	`PENDING`, `SCHEDULED`, `FINISHED`, `UNFINISHED` ou `NON_SCHEDULABLE`
`urlPath`	URL do PDF do encaminhamento
`createdAt` / `updatedAt`	Emissão e última alteração, em `dd/MM/yyyy HH:mm:ss`

curl · GET /beneficiary-medical-referrals

curl --location '{{BASE_URL}}/tema/api/beneficiary-medical-referrals' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

curl · GET /beneficiaries/{uuid}/medical-referrals

curl --location '{{BASE_URL}}/tema/api/beneficiaries/UUID_DO_BENEFICIARIO/medical-referrals' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

As duas respostas são uma lista solta, sem o envelope success/message das consultas de beneficiário. Vida sem encaminhamento devolve [].

json

[
  {
    "uuid": "UUID_DO_ENCAMINHAMENTO",
    "beneficiary": {
      "name": "João Silva",
      "uuid": "UUID_DO_BENEFICIARIO",
      "cpf": "34088529014",
      "email": "joao@exemplo.com",
      "birth": "31/12/1989",
      "phone": "5551993949830",
      "isActive": true,
      "client": { "name": "NOME_DO_CLIENTE", "uuid": "UUID_DO_CLIENTE" }
    },
    "specialty": { "name": "Cardiologia", "uuid": "UUID_DA_ESPECIALIDADE", "cbo": "225120" },
    "status": "PENDING",
    "urlPath": "URL_DO_PDF",
    "createdAt": "20/03/2026 06:16:34",
    "updatedAt": "20/03/2026 06:16:39"
  }
]

PENDING é o que ainda pode virar agendamento. Ao agendar, o encaminhamento passa a SCHEDULED. Inativar a vida cancela os encaminhamentos em aberto.

Agendamento de consultas

O fluxo é sempre o mesmo: escolher a especialidade, pegar um horário livre, agendar com o uuid desse horário e abrir o link devolvido na resposta.

GET /tema/api/specialties — o que o cliente pode agendar.
GET /tema/api/specialty-availability — as frações de horário livres no período.
POST /tema/api/appointments — cria a consulta com o availabilityUuid escolhido.
A resposta 201 traz beneficiaryUrl, o link do atendimento.
DELETE /tema/api/appointments/{uuid} — cancela e libera o horário.

GET/tema/api/specialties

Lista as especialidades que o cliente pode agendar. Os UUIDs alimentam a busca de horários e o agendamento.

Parâmetro	Descrição
`name`	Filtra pelo nome da especialidade, por trecho

curl

curl --location '{{BASE_URL}}/tema/api/specialties' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

json

[
  { "name": "Cardiologia", "uuid": "UUID_DA_ESPECIALIDADE_1", "cbo": "225120" },
  { "name": "Dermatologia", "uuid": "UUID_DA_ESPECIALIDADE_2", "cbo": "225135" },
  { "name": "Pediatria", "uuid": "UUID_DA_ESPECIALIDADE_3", "cbo": "225124" }
]

Regra

A especialidade escolhida precisa estar nos planos do beneficiário — é a mesma lista que veio em plans[].plan.specialties. Fora disso, a busca de horários e o agendamento são recusados com 422 e a mensagem A especialidade passada deve estar na lista dos planos do beneficiário.

GET/tema/api/specialty-availability

Lista as frações de agenda livres para a especialidade no período informado.

Parâmetro	Descrição
`specialtyUuid`	Especialidade a consultar
`beneficiaryUuid`	Vida que será atendida
`date`	Dia único, em `dd/MM/yyyy`
`dateInitial` / `dateFinal`	Período, em `dd/MM/yyyy`. Consulte no máximo 30 dias por chamada — é a janela recomendada
`clinicUuid`	Restringe a uma clínica
`otherProfessional`	Busca horários de outro profissional

curl

curl --location --globoff \
  '{{BASE_URL}}/tema/api/specialty-availability?specialtyUuid=UUID_DA_ESPECIALIDADE&dateInitial=14/05/2026&dateFinal=19/05/2026&beneficiaryUuid=UUID_DO_BENEFICIARIO' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE'

json

[
  { "uuid": "UUID_DA_DISPONIBILIDADE_1", "date": "15/05/2026", "from": "09:00", "to": "09:20" },
  { "uuid": "UUID_DA_DISPONIBILIDADE_2", "date": "15/05/2026", "from": "09:20", "to": "09:40" }
]

Especialidade sem agenda no período devolve 200 com []. A resposta é uma lista solta, sem envelope, e traz apenas esses quatro campos.

O uuid da fração é o availabilityUuid do agendamento. Ele vale enquanto o horário estiver livre — reconsulte antes de agendar.

POST/tema/api/appointments

Campo	Tipo	Regra
`beneficiaryUuid`	UUID	Obrigatório. Vida que será atendida; precisa estar ativa
`availabilityUuid`	UUID	Obrigatório. Fração de horário escolhida
`specialtyUuid`	UUID	Obrigatório. Deve estar nos planos da vida
`beneficiaryMedicalReferralUuid`	UUID	Encaminhamento que originou a consulta
`approveAdditionalPayment`	boolean	Ciência de que haverá cobrança avulsa
`otherProfessional`	boolean	Aceita agenda de outro profissional

Sem encaminhamento:

curl

curl --location '{{BASE_URL}}/tema/api/appointments' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json' \
  --data '{
    "beneficiaryUuid": "UUID_DO_BENEFICIARIO",
    "availabilityUuid": "UUID_DA_FRACAO",
    "specialtyUuid": "UUID_DA_ESPECIALIDADE",
    "approveAdditionalPayment": true
  }'

Com encaminhamento:

json

{
  "beneficiaryUuid": "UUID_DO_BENEFICIARIO",
  "availabilityUuid": "UUID_DA_FRACAO",
  "specialtyUuid": "UUID_DA_ESPECIALIDADE",
  "beneficiaryMedicalReferralUuid": "UUID_DO_ENCAMINHAMENTO"
}

Resposta 201 Created (resumida):

json

{
  "uuid": "UUID_DO_AGENDAMENTO",
  "status": "SCHEDULED",
  "type": "scheduled",
  "beneficiary": { "name": "João Silva", "uuid": "UUID_DO_BENEFICIARIO", "cpf": "34088529014" },
  "specialty": { "name": "Dermatologia", "uuid": "UUID_DA_ESPECIALIDADE", "cbo": "225135" },
  "professional": {
    "name": "Nome do profissional",
    "specialties": [ { "name": "Dermatologia", "uuid": "UUID_DA_ESPECIALIDADE", "cbo": "225135" } ],
    "councils": [ { "code": "CRM", "name": "Conselho", "region": "PR", "number": "31709" } ]
  },
  "clinic": { "uuid": "UUID_DA_CLINICA", "name": "Nome da clínica" },
  "detail": {
    "uuid": "UUID_DA_FRACAO",
    "date": "25/09/2026",
    "from": "08:00",
    "to": "08:20"
  },
  "createdAt": "17/09/2026 16:14:32",
  "updatedAt": "17/09/2026 16:14:32",
  "beneficiaryUrl": "URL_DA_CONSULTA"
}

beneficiaryUrl é o link da consulta para o beneficiário. Abra exatamente como veio e libere câmera e microfone — veja as boas práticas.
professional traz os conselhos do profissional (CRM, RQE) e clinic, a clínica do atendimento.
Nas consultas, o agendamento ganha createdBy — quando o agendamento vem pela API, os três campos vêm com API.

Erros comuns no agendamento

As recusas de regra de negócio voltam em 422, com o motivo em message:

resposta 422

{ "message": "Parâmetro availabilityUuid já utilizado em outro agendamento." }

Mensagem	Como resolver
`Parâmetro availabilityUuid obrigatório`	Busque a fração no `GET /specialty-availability`
`Parâmetro availabilityUuid já utilizado em outro agendamento`	O horário foi tomado; reconsulte e escolha outro
`A especialidade passada deve estar na lista dos planos do beneficiário`	Só agende o que está em `plans[].plan.specialties`
Beneficiário inativo	Reative a vida antes de agendar
`Um agendamento sem encaminhamento pode gerar cobrança adicional. Para confirmar, envie o atributo approveAdditionalPayment = true`	Reenvie com `approveAdditionalPayment: true`
`Especialidade informada não pertence ao profissional.`	A fração escolhida é de outra especialidade: reconsulte os horários da especialidade certa
`Agendamento já cancelado.`	O cancelamento não é repetível
`Tipo de agendamento não aceita encaminhamento, somente sessão avulsa`	Psicologia não usa encaminhamento: envie `approveAdditionalPayment: true`

Consultar e cancelar agendamentos

Endpoint	O que faz
`GET /tema/api/appointments`	Lista as consultas do cliente, com filtros
`GET /tema/api/appointments/{uuid}`	Consulta específica, com profissional, horário e `beneficiaryUrl`
`GET /tema/api/beneficiaries/{uuid}/appointments`	Consultas de uma vida
`DELETE /tema/api/appointments/{uuid}`	Cancela a consulta; devolve `204` e libera o horário. Exige 48 horas de antecedência

Filtros aceitos no GET /appointments: beneficiaryUuid, beneficiaryName, specialtyUuid, professionalUuid, date, dateInitial/dateFinal, scheduledAtBegin/scheduledAtEnd e status (SCHEDULED, FINISHED, UNFINISHED, CANCELED).

As respostas dos GET são listas soltas, sem envelope, e o objeto do agendamento é o mesmo do POST, com createdBy a mais. Cancelar devolve 204 sem corpo; o agendamento passa a status: CANCELED e ganha canceledBy. Repetir o cancelamento responde 422 com Agendamento já cancelado.

Para o histórico consolidado — fila e consultas juntas, com hora de início e fim — use GET /appointments/history.

Exemplos de chamada

Uma requisição por endpoint; todas com os três headers.

Listar consultas do cliente

curl · GET /appointments

curl --location --globoff \
  '{{BASE_URL}}/tema/api/appointments?beneficiaryUuid=UUID_DO_BENEFICIARIO&status=SCHEDULED' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Consulta específica

curl · GET /appointments/{uuid}

curl --location '{{BASE_URL}}/tema/api/appointments/UUID_DO_AGENDAMENTO' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Consultas de uma vida

curl · GET /beneficiaries/{uuid}/appointments

curl --location '{{BASE_URL}}/tema/api/beneficiaries/UUID_DO_BENEFICIARIO/appointments' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Cancelar consulta

curl · DELETE /appointments/{uuid}

curl --location --request DELETE '{{BASE_URL}}/tema/api/appointments/UUID_DO_AGENDAMENTO' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

Cancelamento exige 48 horas de antecedência

O DELETE /tema/api/appointments/{uuid} é recusado quando falta menos de 48 horas para o horário agendado, com a mensagem:

mensagem

Não é permitido cancelamento com menos de 48 horas de antecedência.

Cancelando dentro do prazo:

a consulta passa para o status CANCELED;
a fração de horário é liberada e volta a aparecer no GET /specialty-availability;
se a consulta tinha encaminhamento, ele volta para PENDING e pode ser reagendado.

Faltando menos de 48 horas, a consulta continua ativa: remarcar exige acionar o suporte da Rapidoc. Se o beneficiário simplesmente não comparece, o atendimento fica como UNFINISHED no histórico.

Tolerância de espera do médico

Tipo de atendimento	Tempo que o profissional aguarda
Fila de pronto atendimento	2 minutos — depois disso o atendimento é encerrado e a vaga volta para a fila
Consulta agendada	10 minutos a partir do horário marcado

Atendimento encerrado por ausência do beneficiário fica com status UNFINISHED no GET /appointments/history — é assim que o parceiro identifica o não comparecimento.

Histórico de atendimentos

GET/tema/api/appointments/history

Retorna consultas agendadas (scheduled) e atendimentos de fila (emergency), com data e hora de início e fim e a situação de cada atendimento.

Parâmetro	Obrigatoriedade	Descrição
`date`	Condicional	Dia único, no formato `dd/MM/yyyy` (cobre 00:00 a 23:59)
`dateInitial` / `dateFinal`	Condicional	Intervalo em `dd/MM/yyyy`; no máximo 31 dias
`beneficiaryUuid`	Condicional	UUID do beneficiário
`companyUuid`	Opcional	UUID da empresa vinculada ao beneficiário
`type`	Opcional	`scheduled` ou `emergency`; sem o parâmetro, retorna os dois
`status`	Opcional	`FINISHED`, `UNFINISHED`, `SCHEDULED`, `CANCELED`

É obrigatório informar beneficiaryUuid ou um filtro de data. Use date ou o par dateInitial/dateFinal — não os dois juntos.

curl

curl --location --globoff \
  '{{BASE_URL}}/tema/api/appointments/history?dateInitial=01/07/2026&dateFinal=14/07/2026&type=emergency&companyUuid=UUID_DA_EMPRESA' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

json

[
  {
    "uuid": "UUID_DO_ATENDIMENTO",
    "appointmentBegin": "14/07/2026 14:00:53",
    "appointmentEnd": "14/07/2026 14:01:33",
    "beneficiary": {
      "name": "João Silva",
      "uuid": "UUID_DO_BENEFICIARIO",
      "cpf": "34088529014",
      "email": "joao@exemplo.com",
      "birth": "31/12/1989",
      "phone": "5551993949830",
      "isActive": true,
      "client": { "name": "NOME_DO_CLIENTE", "uuid": "UUID_DO_CLIENTE" }
    },
    "specialty": { "name": "Generalista", "uuid": "UUID_DA_ESPECIALIDADE" },
    "type": "emergency",
    "professional": {
      "name": "Nome do profissional",
      "specialties": [ { "name": "Generalista", "uuid": "UUID_DA_ESPECIALIDADE" } ]
    },
    "status": "UNFINISHED"
  }
]

A resposta é uma lista solta, sem envelope, e período sem atendimento devolve []. As recusas de parâmetro voltam em 422:

Situação	message
Nenhum filtro informado	`Parâmetro beneficiaryUuid ou (date, dateInitial & dateFinal) obrigatório.`
`dateInitial`/`dateFinal` com mais de 31 dias	`Parâmetro dateInitial e dateFinal devem ter no maximo 31 dias de diferença.`

Observações:

Em emergency, apenas atendimentos da especialidade Generalista são retornados.
emergency lista apenas atendimentos que aconteceram: uma entrada na fila abandonada pelo beneficiário não aparece.
Para emergency, status é FINISHED (atendido) ou UNFINISHED (não atendido); para scheduled, também há SCHEDULED e CANCELED.
Com beneficiaryUuid e sem filtro de data, a consulta traz o histórico da vida inteiro, incluindo agendamentos futuros e cancelados.
A data de nascimento em beneficiary vem no campo birth, e o specialty deste endpoint não traz cbo.

GET/tema/api/cid-report

Quantidade de consultas realizadas por CID no cliente autenticado, num intervalo de até 90 dias. Exclui no-show e consultas sem CID.

Parâmetro	Obrigatoriedade	Descrição
`dateInitial` / `dateFinal`	Obrigatório	Período em `dd/MM/yyyy`; no máximo 90 dias
`cids`	Opcional	Faixa ou lista de CIDs, ex.: `J00-J99` ou `J00,R05,J06.9`

curl

curl --location --globoff \
  '{{BASE_URL}}/tema/api/cid-report?dateInitial=01/07/2026&dateFinal=29/09/2026&cids=J00-J99,R05' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

json

{
  "clientUuid": "UUID_DO_CLIENTE",
  "dateInitial": "01/07/2026 00:00:00",
  "dateFinal": "29/09/2026 23:59:59",
  "cids": "J00-J99,R05",
  "totalConsultations": 42,
  "items": [
    { "cidCode": "J00", "cidValue": "Nasofaringite aguda [resfriado comum]", "total": 18 },
    { "cidCode": "R05", "cidValue": "Tosse", "total": 24 }
  ]
}

totalConsultations e os total de items contam consultas, não pacientes distintos. Período sem consulta com CID devolve items: [] e totalConsultations: 0. As recusas de parâmetro voltam em 422:

Situação	message
dateInitial/dateFinal ausentes	`dateInitial e dateFinal são obrigatórios (formato dd/MM/yyyy).`
Data em formato inválido	`dateInitial/dateFinal em formato inválido — use dd/MM/yyyy.`
`dateInitial` depois de `dateFinal`	`dateInitial não pode ser depois de dateFinal.`
Período com mais de 90 dias	`O período do relatório não pode passar de 90 dias.`
`cids` em formato inválido	`Filtro de CIDs inválido — use códigos ou faixas separados por vírgula (ex.: J00-J99, R05, J06.9).`

Privacidade

Este relatório nunca retorna dado identificável do paciente — só a contagem de consultas agrupada por CID.