Changelog

client_user_ref agora garante idempotência de re-tentativas. Ao criar uma sessão de verificação hospedada (POST /api/v1/client/verification-sessions), passar um client_user_ref estável (o ID da pessoa no seu sistema) faz com que re-tentativas da mesma pessoa reusem a mesma identidade em vez de criar um cadastro novo — e não há nova cobrança por re-verificar a mesma pessoa. Recomendado para fluxos em que o usuário pode recomeçar a verificação (após erro, abandono ou múltiplas tentativas). Sem client_user_ref, cada sessão é tratada como uma pessoa distinta (comportamento inalterado). Vale para kind: "physician" e kind: "student". Zero impacto no consumidor App EM.

Verificação bronze inclui declaração de identidade. No fluxo hospedado, a verificação rápida (bronze) passa a exigir que o médico aceite uma declaração, sob as penas da lei, de que é o titular do CRM informado — camada de responsabilização (o registro do aceite, com data/hora e origem, fica selado para auditoria). É uma etapa dentro da página hospedada; sua integração não muda (mesma criação de sessão e mesmos webhooks). Continua valendo: bronze confirma que o registro profissional existe e está regular; para vínculo de identidade por biometria use prata, e por assinatura digital use ouro. Zero impacto no consumidor App EM.

Verificação é produzida apenas pelo fluxo hospedado. A PRODUÇÃO de qualquer tier passa a acontecer só na superfície hospedada do Lastreo (onde o próprio médico confirma a identidade). POST /client/doctors/{id}/verify-tier passa a responder needs_doctor_action para bronze/prata/ouro ainda não verificados (registra a pendência; a cobrança ocorre na conclusão hospedada) — antes o bronze retornava produced na hora. POST /client/doctors apenas registra/vincula o médico (não produz bronze). O reconhecimento cross-tenant (médico já verificado na rede) continua imediato e gratuito por API — o efeito de rede é preservado. Para verificar um médico ainda não verificado, crie uma sessão (POST /client/verification-sessions) e direcione-o ao embed_url. Ação necessária: se você tratava outcome: "produced" no verify-tier para bronze, passe a tratar needs_doctor_action + fluxo hospedado. Zero impacto no consumidor App EM.

Verificação hospedada agora cobre os três tiers. A página/iframe hospedado (POST /api/v1/client/verification-sessions) passa a apresentar o método de acordo com o required_tier da sessão: bronze (confirmação rápida só com CRM + UF + nome, sem documento), prata (carteira + selfie, já existente) ou ouro (assinatura digital ICP-Brasil — o médico baixa um termo, assina com o certificado AR-CFM e reenvia, tudo dentro do iframe). Antes o iframe só fazia prata. O *Lastreo Link* (reuso de identidade já verificada) continua sempre oferecido. Sem required_tier, o padrão permanece prata (zero impacto em integrações existentes). Os webhooks verification.approved carregam o tier final (bronze/prata/ouro) como antes. Zero impacto no consumidor App EM.

Verificação bronze mais precisa. A aprovação automática (bronze) passa a ser sempre ancorada na confirmação do registro profissional oficial (situação regular + nome conferido), e o casamento de nome ficou mais tolerante a variações legítimas (nome do meio omitido, ordem dos sobrenomes) — menos médicos legítimos reprovados, sem afrouxar a checagem. Sem mudança no contrato da API (mesmos endpoints, schemas e tiers). Zero impacto no consumidor App EM.

Cobertura bronze ampliada. A verificação bronze passa a confirmar o médico também pelo registro profissional oficial (situação regular + nome conferido), ampliando a cobertura para quem não tem atividade assistencial ativa registrada (ex.: atuação exclusivamente privada) — antes esses casos exigiam prata/ouro. Sem mudança no contrato da API (mesmos endpoints, schemas e tiers); apenas mais médicos passam a ser elegíveis a bronze automático. Zero impacto no consumidor App EM.

Piso de tier na verificação hospedada (required_tier). POST /api/v1/client/verification-sessions passa a aceitar required_tier (bronze \|prata \|ouro; aliases basic/silver/strong/gold) — o tier mínimo que a sessão aceita. Com piso definido: o Lastreo Link só conclui se a identidade reusada tiver tier ≥ piso (abaixo disso, o médico é direcionado à verificação completa); e a verificação feita dentro do fluxo hospedado (carteira + selfie = prata) não satisfaz piso ouro — ouro depende de identidade já-ouro via Lastreo Link (a assinatura ICP-Brasil é fora do fluxo hospedado). O campo vale só para kind: "physician" e é devolvido em GET /client/verification-sessions/{id}. Sem required_tier, o comportamento é inalterado. Zero impacto no consumidor App EM.

Lastreo Link — reconhecimento exclusivamente por e-mail. O endpoint do fluxo hospedado POST /embed/v/{token}/recognize agora aceita apenas email no corpo; o campo cpf (antes opcional) foi descontinuado. O reconhecimento entre clientes usa o e-mail verificado como chave e envia o código de confirmação para esse mesmo e-mail — chave e canal de prova de posse coincidem. Sem impacto para quem usa a página hospedada (ela sempre pediu o e-mail); se você chamava o endpoint diretamente enviando cpf, passe a enviar email. Zero impacto no consumidor App EM.

GET /api/v1/client/verification-sessions/{id} agora preenche final_tier para estudantes. Antes vinha null em sessões kind=student (o tier só aparecia no webhook ou em /client/students). Agora final_tier reflete o tier final da sessão independentemente do tipo — bronze/prata/ouro para médico, verified/verified_strong para estudante — e a resposta passa a incluir kind (student \|physician). Você lê o resultado direto do GET, sem lookup adicional. Aditivo (médico inalterado; estudante deixa de vir null).

Verificação de estudante — método documento mais flexível. O comprovante de matrícula agora aceita PDF (além de imagem). Selfie e documento com foto passam a ser opcionais: o tier verified é concedido a partir do comprovante (curso de Medicina + instituição reconhecida + nome conferido); enviar selfie + documento com foto eleva o resultado para verified_strong (identidade vinculada por biometria). Tudo acontece dentro da verificação hospedada — sem mudança na sua integração; apenas garanta que seu código trate verified_strong como estudante verificado (assim como verified).

Verificação de estudante de medicina (identidade que evolui para médico). A verificação hospedada (POST /api/v1/client/verification-sessions) agora aceita kind: "student" (default "physician"). Numa sessão de estudante, a página hospedada oferece dois caminhos — e-mail institucional (código) ou comprovante de matrícula — e confirma que a pessoa é estudante de Medicina em instituição reconhecida. O tier resultante é verified (ou verified_strong com identidade jurídica forte). Liste os estudantes do seu tenant via GET /api/v1/client/students. Os webhooks verification.approved/verification.rejected passam a disparar também para estudantes, com kind: "student" no data. Ciclo de vida: quando o estudante obtém o CRM e se verifica como médico, a MESMA identidade Lastreo migra para médico (sai de /client/students, aparece em /client/doctors com tier bronze/prata/ouro). Guia completo no Fluxo 18.6. Zero impacto no consumidor App EM e no fluxo de médico (sessões sem kind continuam sendo de médico).

Valores de tier de verificação agora são bronze / prata / ouro. Os campos que retornam o tier — final_tier (sessões de verificação hospedada), tier (webhooks verification.submitted/approved/rejected), verification_tier (médicos em GET /api/v1/client/doctors e no snapshot de compliance) — passam a emitir prata (antes basic) e ouro (antes strong). bronze é inalterado. As chaves de by_tier no snapshot de compliance passam de basic/strong para prata/ouro. Os nomes antigos continuam aceitos na ENTRADA (POST /client/doctors/{id}/verify-tier, override de admin): basic/silver → prata, strong/gold → ouro. Ação necessária: se você compara o tier como string no seu lado (ex.: if (tier === "basic")), atualize para os novos valores prata/ouro.

**Endpoints de integração /client/* aceitam X-API-KEY (server-to-server). Antes só Bearer JWT de client_admin (dashboard). Agora os endpoints de integração — POST/GET /api/v1/client/verification-sessions, POST/GET /api/v1/client/doctors, POST /api/v1/client/doctors/{id}/verify-tier, GET /api/v1/client/verifications/usage, GET /api/v1/client/usage, GET /api/v1/client/usage/by-patient, GET /api/v1/client/compliance/snapshot — aceitam X-API-KEY: lk_... (a forma recomendada para o backend do seu sistema chamar o Lastreo: revogável, escopada ao tenant, sem credencial de login no servidor) ou Bearer JWT (dashboard). Crie a API key no dashboard em Developer → API Keys (mostrada uma vez). Endpoints de gerenciamento de conta (api-keys, webhooks, integrações, push-configs, devices) seguem exclusivos do dashboard via JWT — não se gerencia uma API key usando uma API key. Zero impacto no consumidor App EM.**

Correlação de webhooks de verificação por sessão (estilo client_reference_id do Stripe). Quando você cria uma sessão de verificação hospedada (POST /api/v1/client/verification-sessions), pode passar um client_user_ref — o identificador do médico no seu próprio sistema. A partir de agora, os webhooks de verificação originados daquela sessão carregam no data os campos session_id e client_user_ref, permitindo correlacionar o webhook ao seu usuário sem nenhum lookup reverso — independentemente da ordem em que o webhook e a resposta de criação chegam. session_id é exatamente o mesmo campo session_id (string pública vs_…) que o POST /client/verification-sessions devolveu no corpo da resposta — NÃO o id numérico (PK interna). Eventos afetados: verification.submitted, verification.approved, verification.rejected. Isolamento multi-tenant garantido: como o médico é uma entidade global (o mesmo CRM pode existir em vários clientes Lastreo), o evento de verificação é entregue a todos os clientes que conhecem aquele médico — mas session_id/client_user_ref são incluídos somente no webhook do cliente dono da sessão. Os demais clientes recebem o mesmo evento sem esses campos. Eventos que não vêm de uma sessão hospedada (ex.: cadastro bronze via POST /api/v1/client/doctors, verificação ICP-Brasil feita diretamente pelo médico) não trazem esses campos — continue usando o user_id do médico. Exemplo de data recebido pelo cliente dono: {"user_id": 42, "tier": "prata", "verified_crm": "123456", "verified_uf": "SE", "session_id": "vs_ab12cd34", "client_user_ref": "seu-sistema:medico:789"}. Nenhuma ação necessária se você não usa sessões hospedadas (campos só aparecem quando há client_user_ref na sessão).

Billing de verificação por tier. Endpoints novos para client_admin: GET /api/v1/client/verifications/usage?days=N (contagem de verificações por tier no período + total, quota mensal do plano, overage e estimativa de billing mensal em BRL) e POST /api/v1/client/doctors/{doctor_id}/verify-tier com body {"tier": "bronze"\|"prata"\|"ouro"} (aliases legacy basic/strong/silver/gold também aceitos). Regra de cobrança: você paga pela verificação de um tier quando ela é produzida pela primeira vez para aquele médico; se ele já tem aquele tier (ou superior) porque já foi verificado antes na rede Lastreo, o reconhecimento é gratuito. Subir de tier conta como verificação nova. O verify-tier responde recognized (grátis), produz o tier na hora (bronze), ou needs_doctor_action para prata/ouro (o médico completa pelo fluxo próprio e a cobrança ocorre na aprovação). Preços vigentes em /docs-public/pricing.html. Zero impacto no consumidor App EM (endpoints do dashboard B2B).

BYOK (chave de IA própria) passa a ser obrigatório. Todo tenant precisa configurar uma integração de IA em /dashboard/integrations/ (aba IA / Modelo) antes de usar o chat. Sem BYOK: o chat retorna um erro estruturado pedindo a configuração; POST /chat/send com upload de mídia retorna HTTP 422; e o resumo automático de conversa é silenciosamente omitido (o chat de texto segue funcionando). Para upload de mídia e resumo de conversa, a chave precisa ser de um provider compatível com a Files API do Gemini (openai_compatible apontando para o endpoint do Gemini, ou google_native); outros providers atendem o chat de texto mas não mídia/resumo. Zero impacto para quem já tem BYOK configurado.

Lastreo Link — reuso da identidade verificada entre clientes. Um médico já verificado em qualquer cliente Lastreo pode confirmar a identidade em um cliente novo via código enviado por email e herda o tier na hora, sem reenviar documentos (opt-in explícito do médico, LGPD Art. 7). Endpoints do fluxo hospedado: POST /embed/v/{token}/recognize (informa o e-mail cadastrado, dispara o código), POST /embed/v/{token}/recognize/confirm (valida o código e herda a identidade — o webhook de aprovação carrega via_lastreo_link: true), POST /embed/v/{token}/link-consent (opt-in/opt-out do reuso). Efeito de rede: cada cliente novo amplia a base de médicos reconhecíveis pelos próximos. Zero impacto no consumidor App EM.

Verificação hospedada (modal embed estilo Stripe Elements). Crie uma sessão via POST /api/v1/client/verification-sessions (recebe embed_url) e consulte o resultado via GET /api/v1/client/verification-sessions/{id}. A página hospedada é um wizard de 4 passos (identificação → carteira → selfie → resultado) com tema customizável (theme_primary_color), branding opcional (hide_branding, para white-label) e redirect ao concluir (completion_redirect_url). SDK JS drop-in em /dashboard/sdk/lastreo.js (Lastreo({embedUrl}).mount(...) ou .openModal(...)). A foto da carteira e a selfie vão direto para o Lastreo — nunca passam pelo seu backend. Sob LGPD, você deixa de ser controlador do dado biométrico. Zero impacto no consumidor App EM.

Verificação prata com decisão automática. A submissão de tier prata (POST /doctors/me/verification/basic/submit) passa por uma avaliação automática que pode aprovar, rejeitar ou encaminhar para revisão humana — sem que documento ou biometria saiam da infraestrutura Lastreo (zero data egress). Os webhooks verification.approved / verification.rejected passam a carregar auto_approved / auto_rejected e um indicador de confiança da decisão. Nenhum subprocessador novo; nenhum dado sai do servidor Lastreo. Zero impacto no consumidor App EM.

Compliance snapshot. Novo endpoint GET /api/v1/client/compliance/snapshot retorna uma prova-de-tratamento estruturada (médicos por tier, registros oficiais consultados com data da última atualização, atividade de auditoria do período, DSRs e incidentes, atestações LGPD) — um JSON que você pode anexar a contratos comerciais ou apresentar em inquérito da ANPD. Acompanha reorganização do dashboard B2B em torno de verificação + compliance. Zero impacto no consumidor App EM.

Refinamento interno da verificação bronze (melhor detecção de registros profissionais com status irregular). Sem mudança de contrato da API. Zero impacto no consumidor.

Cadastro de médico pelo cliente B2B com verificação automática. POST /api/v1/client/doctors (role client_admin): envie {full_name, crm, uf, specialty?, email?} e o médico é criado já com tentativa de verificação automática. Se elegível, retorna verification_tier=bronze + status=approved em instantes; caso contrário fica pendente para prata/ouro. A resposta inclui bronze_attempted, bronze_eligible e bronze_reason para você decidir o fluxo. Cadastros repetidos do mesmo médico (por email ou por CRM/UF) atualizam em vez de duplicar. Zero impacto no consumidor existente (endpoint novo).

Tier bronze — verificação automática sem documento físico. Novo tier bronze (abaixo de basic/strong). Endpoint POST /api/v1/doctors/me/verification/bronze (rate-limited): cruza o CRM/UF declarados com registros oficiais e aprova na hora quando há correspondência sem pendências, derivando a especialidade automaticamente. Casos que não passam seguem para os fluxos prata/ouro. O webhook verification.approved pode agora trazer tier=bronze. Zero impacto no consumidor existente (tier novo; basic/strong inalterados).

Ferramentas internas de apoio à revisão de verificações prata (uso administrativo Lastreo). Endpoints internos apenas para admin; zero impacto no consumidor App EM.

Configuração de push (FCM) por evento. Endpoints /api/v1/client/*: GET /push-configs (catálogo de eventos alert.created + medication_reminder.due com a config do tenant), PUT /push-configs/{event_type} (enabled + custom_title/custom_body opcionais), DELETE /push-configs/{event_type} (volta ao default), GET /devices (device tokens FCM dos usuários do tenant), POST /push-test (push de teste para um device). Eventos de médico (verification.approved/rejected) não são configuráveis (médico é global; push sempre dispara). Gerenciável em /dashboard/events/. Zero impacto no consumidor App EM (default enabled=true preserva o comportamento atual).

Push nativo (FCM) em aprovação/rejeição de verificação. Quando a verificação de um médico é aprovada ou rejeitada, o Lastreo dispara push para o device token registrado (POST /api/v1/users/me/device-tokens), com data {type:"verification", approved, tier, doctor_user_id} para deep-link. O webhook verification.rejected passou a ser emitido também (antes só o approved). Zero impacto no consumidor App EM (sem device token, vira no-op).

Mudança interna de configuração de autenticação serviço-a-serviço. SERVICE_API_KEY continua válida indefinidamente. Zero impacto no consumidor App EM.

Atribuição de uso de IA por tenant e por paciente. GET /api/v1/client/usage passa a refletir corretamente o consumo do tenant (inclui chamadas de médico atendendo paciente do tenant). Endpoint novo GET /api/v1/client/usage/by-patient?days=N&limit=M retorna ranking de pacientes por consumo de IA + bloco unattributed para chamadas sem paciente-alvo. Zero impacto no consumidor App EM (analytics).

Painel de integrações BYOK + visibilidade de médicos. /dashboard/integrations/ com abas IA / WhatsApp / Telegram (forms não-destrutivos — o segredo só é atualizado se preenchido). Página /dashboard/doctors/ read-only: a verificação de médico é centralizada no Lastreo (1 CRM = 1 médico, entidade global); o cliente recebe o resultado por webhook, mas não aprova/rejeita. Endpoint GET /api/v1/client/doctors lista os médicos verificados que atendem pacientes do tenant (com verification_status, verification_tier, verified_crm, verified_uf, verified_specialty, patient_count_in_tenant). Zero impacto no consumidor App EM.

Roteamento de webhook de mensageria por tenant (BYOK). O webhook do WhatsApp passa a identificar o tenant pelo phone_number_id do payload e validar a assinatura com o segredo do próprio tenant. Endpoint novo /webhooks/telegram/{path_token} por tenant. O envio de mensagens usa as credenciais do tenant. Suporte a mais um provider de IA. Zero impacto no App EM (sem integração própria, segue no padrão).

BYOK — Bring Your Own Key (Fase 1). Cliente pluga a própria chave de IA (OpenAI / Mistral / modelo local compatível com OpenAI / Gemini) e o chat passa a rodar nela. Endpoints /api/v1/client/integrations/{ai,whatsapp,telegram} (GET/PUT/DELETE), com os segredos criptografados at rest. Zero impacto no consumidor App EM.

Páginas públicas + request access. Páginas em /docs-public/: pricing, legal (ToS + DPA + AUP + Privacy), request-access. Endpoint público POST /api/v1/public/access-request (rate-limited, sem auth, com anti-spam). Endpoints admin para revisar pedidos. Zero impacto no consumidor App EM.

Dashboard self-service B2B (frontend). https://lastreo.com/dashboard/ — login + páginas de overview, API keys, webhooks, uso, erros e configurações. Zero impacto no consumidor App EM.

Dashboard self-service B2B (backend). Role client_admin + endpoints **/api/v1/client/* para o cliente gerenciar o próprio tenant: /me, /api-keys (CRUD + revoke), /webhooks (CRUD + deliveries + retry + test), /usage, /errors. Zero impacto no consumidor App EM.**

Ambiente sandbox. https://lastreo.com/sandbox/ — isolado de produção, com stubs para IA/FCM/email/mensageria (não enviam de verdade). Troque a base URL e teste fluxos completos sem afetar produção nem consumir cota de IA. Zero impacto no consumidor App EM (produção segue em /api/v1/...).

Status page + changelog público. /docs-public/status.html e /docs-public/changelog.html. Endpoint público GET /status agrega estado operacional + estatísticas de webhook 24h + incidentes recentes (sem expor detalhes sensíveis). Zero impacto no consumidor.

Webhooks B2B. Cada cliente configura webhooks (URL + segredo + lista de eventos). Assinatura HMAC SHA-256 no header X-Lastreo-Signature: t=<ts>,v1=<hex> — valide com o seu segredo. Retry em 1m/5m/30m/2h/6h (5 tentativas). Eventos publicáveis: verification.approved/rejected/submitted, alert.created, assessment.created, symptom.recorded, medication_reminder.due, patient.created/merged/deleted, dsr.created, incident.notified. Zero impacto no consumidor App EM (sem webhook configurado, sem efeito).

Observabilidade interna (rastreamento de erros, uso administrativo Lastreo). Zero impacto no consumidor.

Segurança técnica. Dados sensíveis (CPF, telefone) criptografados em repouso; TLS no banco de dados; backup automatizado e criptografado com retenção. Endpoints GET /health (liveness) e GET /health/ready (readiness com checagem de DB). Zero impacto no consumidor.

Consent tracking versionado (LGPD Art. 8 + 18 IX). Endpoints públicos: GET /consents/current (versão vigente por tipo) e GET /consents/{type}/{version} (conteúdo). Titular: POST /users/me/consents, POST /users/me/consents/{id}/revoke, GET /users/me/consents. Auto-consent no /auth/register para documentos vigentes. Zero impacto no consumidor.

Notificação de incidente de segurança (LGPD Art. 48). O Lastreo, como operador, notifica os clientes afetados por um incidente de dados; o webhook incident.notified sinaliza o cliente em tempo real. Zero impacto no consumidor.

Direitos do titular automatizados (LGPD Art. 18 + 20). Endpoints: POST /data-subject-requests (titular cria; alguns tipos são processados automaticamente), GET /users/me/data-subject-requests, GET /data-subject-requests/{id}; a fila é gerida pelo admin. GET /subprocessors lista pública de sub-operadores (Art. 18 VII). 9 direitos cobertos. Zero impacto no consumidor.

Expansão do registro de auditoria interno em rotas críticas (forense + LGPD). Zero impacto no consumidor.

Registro de auditoria (base de compliance LGPD). Endpoints: GET /admin/audit-log (admin) e GET /users/me/audit-log (titular — LGPD Art. 18 II + VII). Ações sensíveis ficam registradas com ator, alvo e timestamp, de forma imutável. Zero impacto no consumidor App EM.

Isolamento cross-tenant aplicado em todos os endpoints clínicos secundários (assessments, health-registries, alerts, medication-reminders, exports, dashboards, gestão de pacientes). Zero impacto no consumidor App EM — as queries seguem retornando os mesmos resultados; acesso cross-tenant retorna 404.

Paciente passa a ser escopado por cliente. Zero impacto no consumidor App EM: listagens e leituras de paciente filtram pelo cliente atual; acesso cross-tenant retorna 404. Médico permanece global (1 CRM = 1 conta Lastreo). Email de paciente único por cliente; email de médico único globalmente.

Fundação multi-tenant interna. Zero impacto no consumidor — X-API-KEY continua idêntico; nenhum endpoint mudou shape de request/response. Compromisso de estabilidade /v1 documentado.

Verificação profissional de médicos em dois caminhos: ouro (assinatura digital ICP-Brasil AR-CFM, aprovação imediata e automatizada) e prata (envio de foto da carteira CRM + selfie para análise manual em até 24h). verification_tier (strong/basic/null) adicionado a UserOut e ao status de verificação. Caminho ouro: POST /doctors/me/verification/terms (sem body — usa full_name do perfil), POST /doctors/me/verification/submit, GET /doctors/me/verification/status. Caminho prata: POST /doctors/me/verification/basic/submit, GET /doctors/me/verification/basic. Ver Fluxo 17

Perfil: UserOut agora inclui phone_number, date_of_birth, biological_sex, cpf, address_city, address_state, crm e medical_specialty (todos opcionais). Novos endpoints: PATCH /users/me (usuário edita próprio perfil), PATCH /doctors/me/patients/{id} (médico edita paciente provisório), POST /auth/change-email + POST /auth/confirm-email-change (troca de email autenticada com código de confirmação)

Pacientes: médico agora pode remover paciente da lista (DELETE /doctors/me/patients/{id}). Se o paciente for provisório, é apagado junto com todos os seus dados clínicos; se for real, apenas desassocia (conta preservada)

Pacientes: médico pode criar paciente provisório com apenas o nome (POST /doctors/me/patients/provisional) e mesclar com conta real posteriormente (POST /doctors/me/patients/{id}/merge). UserOut agora inclui is_provisional e email pode ser null. Bugfixes no pipeline de chat: tool calling corrigido, unicode corrigido em respostas de ferramentas, mensagens internas filtradas do histórico

Chat: arquitetura split send + SSE — POST /send retorna imediatamente com ID, resposta da IA via GET /stream (Server-Sent Events). Suporte a local_id para idempotência e correlação cliente-servidor

Chat: paginação por cursor (before_id/before), ordenação DESC (mais recente primeiro). Auth: endpoint de alteração de senha (change-password)

Base URL atualizada para HTTPS com domínio estável (lastreo.com)

Migração de servidor: nova Base URL, seção de conexão adicionada

Push Notifications (FCM): Fluxo 16 — gerenciamento de device tokens para notificações push nativas Android/iOS

Chat In-App: documentação sobre gerenciamento de contexto de conversa (janela deslizante + resumo automático)

Chat In-App (POST /send, GET /history, DELETE /history — alternativa REST ao WhatsApp/Telegram para chat direto no App EM)

Alertas clínicos (API + threshold automático + notificação médicos), lembretes de medicação (CRUD + scheduler), 4 novos tipos Health Connect (SLEEP, NUTRITION, HYDRATION, HEART_RATE), export FHIR R4

Health Registries: upsert via external_id (deduplicação Health Connect), DELETE individual e DELETE ALL (LGPD)

Adicionados: Fluxo 10 (Analytics e Dashboards — dashboard do médico, tendências de sintomas, correlação saúde×exercício), Fluxo 11 (Export de Dados Clínicos — CSV e PDF)

Adicionado: Fluxo 9 (Verificação de Email), campo email_verified na resposta do usuário, envio automático de código de verificação no registro

Melhorias de performance e estabilidade no processamento de mensagens

Adicionados: Fluxo 7 (Registros de Saúde / Health Connect), Fluxo 8 (Recuperação de Senha), endpoints de batch e summary para health registries

Adicionados: campos EDSS atualizados, Fluxo 5 e 6 (Paciente e Médico)