BabyCare

Escopo do parceiro de consumo

Headers

Todas as chamadas levam os três headers da API TEMA v2:

Datas nas respostas

Todo campo de data das respostas (createdAt) já vem formatado como string dd/MM/yyyy HH:mm:ss no fuso GMT-3 (ex.: "01/09/2026 14:20:05") — não é epoch e não precisa de new Date(...). Os valores enviados na query (dateInitial/dateFinal) seguem o formato dd/MM/yyyy.

BabyCare

Classifica o choro de bebê a partir de áudio em tempo real. O beneficiário-alvo é a criança. Exige o produto babycare ativo no cliente e o parâmetro HAS_BABY_CARE = true na criança — faltando qualquer um dos dois, o envio de áudio devolve 422.

Streaming de áudio

POST .../audio recebe cada chunk de ~1 s de áudio bruto no corpo da requisição — não é upload de arquivo, é leitura ao vivo do microfone, enviada em loop. Content-Type é application/octet-stream nesse endpoint (exceção à regra geral da API).

curl --location '{{BASE_URL}}/tema/api/beneficiary-babycare-scans/UUID_DA_CRIANCA/audio' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/octet-stream' \
  --header 'x-audio-sample-rate: 16000' \
  --header 'x-audio-timestamp: 0' \
  --data-binary '@chunk.pcm'

A resposta é repassada como veio do serviço de análise, sem desserialização — traz um campo phase (partial ou done). Envie chunks em loop, incrementando x-audio-timestamp em 1000 a cada chunk, até receber phase: "done" — é nesse momento que o resultado (tipo de choro) é gravado automaticamente. Beneficiário ou cliente não elegíveis ao BabyCare: 422. Falha ao comunicar com o serviço de análise: 502.

Implementação: captura e envio dos chunks

O fluxo de quem envia é sempre o mesmo, independente da linguagem: capturar áudio do microfone (ex.: Web Audio API no navegador), fatiar em blocos de ~1 s, converter cada bloco para PCM linear mono 16-bit little-endian (sem cabeçalho de arquivo) e enviar em loop — um POST .../audio por bloco, incrementando x-audio-timestamp em 1000 a cada envio, até a resposta trazer phase: "done" ou um erro.

Cada resposta precisa ser conferida antes do próximo envio: um 422 ou 502 interrompe a sessão — não adianta continuar mandando chunks; phase: "done" também encerra, é o sinal de que o resultado já foi classificado e gravado.

A forma segura é o navegador nunca falar direto com o TEMA: ele captura e envia o chunk para um endpoint do seu próprio backend — ou um middleware (ex.: Next.js), não precisa ser necessariamente um backend dedicado — que guarda o clientId/token do lado do servidor (variável de ambiente, nunca no bundle do front) e repassa a chamada para o TEMA, devolvendo a resposta ao navegador.

O navegador só precisa saber o beneficiaryUuid e os headers de formato do áudio (x-audio-sample-rate, x-audio-timestamp) — quem sabe o clientId e o token é o backend.

Histórico de escaneamentos

Histórico da criança — GET /tema/api/beneficiary-babycare-scans/{uuid}?period=week

curl --location '{{BASE_URL}}/tema/api/beneficiary-babycare-scans/UUID_DA_CRIANCA?period=week' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/vnd.rapidoc.tema-v2+json'

[
  { "uuid": "UUID_DO_SCAN", "cryType": "HUNGRY", "createdAt": "01/09/2026 03:12:44" },
  { "uuid": "UUID_DO_SCAN", "cryType": "SLEEP", "createdAt": "31/08/2026 22:40:03" }
]

period aceita week (semana corrente) ou month (padrão). Valores de cryType: HUNGRY (fome), SLEEP (sono), PAIN (dor), BURP (necessidade de arrotar), UNCOMFORTABLE (desconforto).

Passo a passo de implementação

Sequência mínima para integrar o BabyCare — os detalhes de cada chamada estão nas seções acima.

Uso nas telas do app

Exige app com captura de microfone.

Protocolo de áudio

Especificação do que viaja no body de POST /tema/api/beneficiary-babycare-scans/{beneficiaryUuid}/audio — para implementar o cliente do zero, em qualquer stack, reproduzindo exatamente o que o TEMA espera.

É leitura ao vivo, não upload de arquivo. O app abre o microfone e vai enviando o som enquanto o choro acontece, em blocos de 1 s, um atrás do outro. Nada é gravado nem montado como .wav/.mp3 antes — cada bloco é um pedaço do stream capturado naquele segundo. O TEMA processa cada bloco e devolve o andamento da sessão.

01 · O body é áudio cru, não um arquivo

Não é JSON, não é base64, não é um .wav com header. É PCM puro: a sequência de amostras de 16 bits, little-endian, mono, sem nenhum envelope em volta. Cada amostra ocupa 2 bytes, byte menos significativo primeiro. Não há cabeçalho: o primeiro byte do body já é o byte baixo da amostra 0.

1 segundo de áudio = n amostras × 2 bytes   (n = sample rate)

 8 kHz  →  8.000 amostras/s × 2 = 16.000 bytes por bloco
16 kHz  → 16.000 amostras/s × 2 = 32.000 bytes por bloco

02 · Headers de cada requisição

Vão junto do binário, nunca dentro dele:

curl --location '{{BASE_URL}}/tema/api/beneficiary-babycare-scans/UUID_DA_CRIANCA/audio' \
  --header 'Authorization: Bearer SEU_TOKEN' \
  --header 'clientId: UUID_DO_CLIENTE' \
  --header 'Content-Type: application/octet-stream' \
  --header 'x-audio-sample-rate: 16000' \
  --header 'x-audio-timestamp: 0' \
  --data-binary '@chunk.pcm'

03 · x-audio-timestamp

Milissegundos desde o início da sessão. 0 no primeiro bloco e +1000 a cada bloco seguinte (1000, 2000, 3000…), porque cada bloco carrega 1 s de áudio. É o relógio da sessão — não é epoch e não reinicia entre blocos; só volta a 0 quando você inicia uma sessão nova.

04 · O loop no app

1. Pedir permissão de microfone e abrir a captura (Web Audio AudioContext + getUserMedia, ou o equivalente nativo).
2. Reamostrar para 16 kHz (ou 8 kHz) e converter de Float32 [-1, 1] para Int16 little-endian.
3. Acumular 1 s de amostras e disparar o POST — sequencial, um bloco por vez, x-audio-timestamp em 0, 1000, 2000…
4. A resposta é o andamento da sessão em JSON (phase e, ao final, answer). Enquanto phase ≠ "done", siga enviando.
5. Quando vier phase: "done" com answer, encerre a captura — nesse momento o TEMA grava o escaneamento com o cryType. Depois é só chamar o GET de histórico.

Erros e limites

• 422 — criança sem HAS_BABY_CARE = true ou cliente sem o produto babycare. Cheque antes (tela 1) para não abrir a captura à toa.
• 502 — falha no serviço de análise; normalmente é reiniciar a sessão do zero.
• O áudio não é armazenado em nenhum lugar — só o cryType resultante.
• A latência é sensível: 1 bloco por segundo, sequencial. Mantenha os blocos em ~1 s e não acumule vários antes de enviar.

Apresentação de telas

Mockup para visualizar como o fluxo aparece para o beneficiário e a qual chamada cada tela corresponde. Não é a UI real.

Checklist

Valide em sandbox antes de ir para produção. Os itens marcados ficam salvos neste navegador.