Changelog

Vinculação de conta a um canal passa a transferir o histórico completo — e o isolamento por cliente cobre também os painéis do médico. POST /api/v1/users/claim-confirm (vincular WhatsApp/Telegram a uma conta, herdando o que já havia sido registrado no atendimento) transferia apenas parte dos registros: quando a ficha tinha avaliações clínicas, alertas ou lembretes de medicação, a chamada falhava com 500. Agora transfere tudo — avaliações, sintomas, registros de saúde, alertas, lembretes, canais de contato e os vínculos com médicos — e a ficha precisa pertencer ao mesmo cliente da conta que reivindica (caso contrário, 404). Na mesma linha, GET /api/v1/doctors/me/alerts, /alerts/unread-count, PATCH /alerts/{id}/read e GET /doctors/me/dashboard passam a considerar apenas os pacientes do cliente atual — o mesmo escopo já aplicado em /patients/* desde a v1.31/1.32 e completado na busca em v1.79. Como o médico é uma entidade global (o mesmo CRM pode atender em vários clientes Lastreo), esses endpoints eram os últimos que derivavam a lista de pacientes sem esse filtro. Zero impacto no consumidor App EM — com um único cliente, o resultado é o mesmo.

Selfies e fotos de documento enviadas de celular passam a ser analisadas na orientação correta. Fotos tiradas em retrato eram armazenadas deitadas (a orientação registrada pela câmera não estava sendo aplicada), o que inviabilizava a checagem facial — na prática, nenhuma selfie tinha rosto reconhecido. Corrigido: a orientação é aplicada antes do armazenamento. Efeito direto na taxa de aprovação automática da verificação prata. Quem já enviou fotos antes desta versão pode precisar reenviar.

Menos recusas indevidas na verificação prata. Fotos de carteira legíveis para uma pessoa, mas difíceis para a leitura automática (reflexo, holograma, ângulo), podiam gerar recusa automática mesmo com os registros oficiais confirmando o profissional. Nesses casos a submissão passa a seguir para análise em vez de ser recusada. Sem mudança de contrato — mesmos endpoints, mesmos estados (pending_review / approved / rejected); apenas menos falsos negativos. Submissões sem confirmação nos registros oficiais continuam sendo recusadas.

Fotos direto da câmera do celular agora são aceitas: modo "movimento"/"live" (Android) e HEIC (iPhone). Dois formatos que o usuário não escolhe e nem percebe eram recusados: o modo movimento entrega um arquivo com extensão .jpeg que internamente tem quadros extras, e o iPhone salva em HEIC por padrão. Ambos passam a ser aceitos e convertidos para JPEG. Vale para todos os envios de imagem: verificação prata, verificação de estudante e mídia no chat. Nenhuma mudança para quem já enviava fotos normais; formatos realmente não suportados continuam recusados.

Reenvio de verificação mais permissivo, e limite por conta. O submit de verificação (prata e estudante) passa de 2 por dia para 5 por hora — corrigir uma foto ruim não espera mais até o dia seguinte. Além disso, os limites de requisição em endpoints autenticados agora contam por conta, não por endereço de rede: antes, usuários diferentes atrás de um mesmo ponto de saída podiam dividir o mesmo limite (e receber 429 sem terem excedido nada). Sem mudança de contrato — só de comportamento dos limites.

Correção no envio de arquivos: uploads acima de 1 MB no total não são mais rejeitados. Requisições multipart (fotos da verificação prata/estudante, mídia do chat, PDF da verificação ouro) com corpo total acima de 1 MB eram barradas antes de chegar à API, com resposta 413 em HTML — na prática, o envio de 2 fotos reais de verificação falhava. Corrigido: o limite passa a ser 8 MB por arquivo e 25 MB por requisição; exceder retorna erro em JSON, no mesmo formato do resto da API ({"detail": "..."}). Nenhuma mudança para quem já enviava arquivos pequenos.

Correção no ambiente de sandbox: POST /auth/register voltou a funcionar sem X-API-KEY. No sandbox, criar conta sem enviar a chave de API retornava 500, porque o ambiente resolvia o cliente padrão por um identificador que só existe em produção. Produção inalterada.

Isolamento cross-tenant aplicado à busca de pacientes. GET /api/v1/patients/search passa a restringir o resultado ao cliente atual, o mesmo escopo já aplicado em /patients/{id} e nas listagens desde a v1.31/1.32. Completa a cobertura do isolamento: por devolver uma lista em vez de receber um patient_id, este era o único endpoint de paciente fora da regra. Zero impacto no consumidor App EM — a busca segue retornando os mesmos resultados.

Exclusão de conta pelo próprio usuário (POST /auth/delete-account). Novo endpoint autenticado que exclui a conta do titular, confirmado pela senha atual (rate limit 3/hora). Efeito imediato: os dados pessoais e clínicos são apagados, os documentos enviados saem do armazenamento, as sessões são encerradas e o endereço de email volta a ficar livre para um novo cadastro na mesma hora — inclusive com outro papel, resolvendo o caso de quem se cadastrou como paciente quando queria medico (ou vice-versa) e ficava sem saída. Os tokens da conta excluída deixam de valer mesmo que o endereço seja reutilizado depois. Registros mantidos por obrigação legal (comprovação de cobrança de verificação e trilha de auditoria) são preservados sem vínculo com a pessoa. Contas administrativas não são excluídas por este endpoint (403). Detalhes na seção 8.4. Aditivo — zero impacto em quem não chamar o endpoint.

Novo evento lastreo.verify.error no embed + sandbox cobre o fluxo hospedado. A página hospedada (iframe) passa a emitir um postMessage lastreo.verify.error (com message) quando a sessão não pode ser carregada — link inválido, expirado ou já usado —, permitindo ao seu app reagir (mostrar aviso, pedir novo link). Além disso, o sandbox passa a exercitar o fluxo hospedado de verdade: crie uma sessão no sandbox e abra o embed_url retornado (resolve contra o sandbox); e dá pra explorar o dashboard do sandbox em /dashboard/login/?env=sandbox com a conta cliente-demo. Zero impacto no consumidor App EM (o evento novo é aditivo — quem não o escuta não é afetado).

Piso de tier para estudante na verificação hospedada (student_required_tier). POST /api/v1/client/verification-sessions passa a aceitar student_required_tier (verified \|verified_strong; aliases strong/forte) em sessões kind: "student" — o tier mínimo que a sessão aceita. Com verified_strong, a página hospedada exige comprovante de matrícula + documento oficial com foto + selfie (identidade vinculada por biometria) e o método de e-mail institucional sozinho não conclui a sessão; se a análise só alcançar verified, a sessão fica pendente de revisão em vez de concluir. Sem o campo, o comportamento é inalterado (o comprovante basta para verified; enviar biometria eleva para verified_strong). Só vale para kind: "student"; devolvido em GET /client/verification-sessions/{id}. Zero impacto no consumidor App EM.

Sandbox self-service para testar verificação. Novo atalho exclusivo do sandbox POST /api/v1/client/sandbox/doctors/{id}/simulate-verification (outcome: approved / rejected / revoked) que simula o resultado de uma verificação e dispara o webhook correspondente apenas aos seus webhooks — permite testar a integração de ponta a ponta (incluindo o recebimento do evento) sem aprovação manual. Em produção o endpoint retorna 404 — a verificação segue sendo conduzida pelo Lastreo. Documentado o ambiente de testes (base https://lastreo.com/sandbox/ + conta cliente-demo) na seção Primeiros Passos. Zero impacto no consumidor App EM.

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)