# Monitoramento de sessão

<https://unifokal.com/docs/modulos/sessao-monitor>

## Monitoramento de sessão

! **Ainda não está aberto para venda.** O módulo aparece na [tabela de preços](https://unifokal.com/precos) com preço e com o selo "Em breve", e o `create` de flow o recusa até a abertura. O endpoint que recebe os eventos do navegador também ainda não está publicado. O contrato de resposta abaixo é o que o backend já emite, para você planejar a integração.

O módulo `sessao_monitor` observa o que acontece **depois** da aprovação. Na sessão já logada do seu site, ele acompanha ações de negócio (depósito, saque, aposta), um sinal de vida a cada trinta minutos, a localização que o navegador conceder e o aparelho. Regras determinísticas rodam no nosso servidor e, quando uma fecha, você recebe um alerta no mesmo webhook assinado de sempre, com o nome da regra, a severidade e a evidência em número.

**A janela, o sinal de vida e os eventos são grátis: você paga só pelo achado.** É o oposto do modelo por chamada: uma sessão de catorze eventos custa zero até encontrarmos alguma coisa. Cada alerta chega no webhook com a regra e a evidência em número.

```
// sessao_monitor no check_details: o alerta de sessão
{ "module": "sessao_monitor", "passed": null, "outcome": "pending", "score": 50,
  "data": { "monitoring": {
      "kind": "session_monitor_alert",       // distingue este evento de uma verificação de onboarding
      "alert_id": "mal_01H…",                // id opaco do achado
      "rule": "impossible_travel_session",   // qual regra fechou
      "severity": "high",                    // high | medium (não existe low)
      "evidence": { "distance_km": 412.7,    // a evidência é NUMÉRICA, nunca a coordenada
                    "interval_min": 18,
                    "implied_kmh": 1375.7 } } } }
```

No resumo `checks` o módulo sai com o **nome da regra** que fechou, ou `"clean"` quando a sessão foi observada e nada fechou. As regras respondem perguntas diferentes e você aciona coisas diferentes em cada uma, então um booleano ali esconderia a informação inteira. As chaves de `evidence` mudam conforme a `rule`, e são sempre números do achado.

! **O alerta nunca recusa ninguém, e isso é estrutural.** O dado vem do navegador do usuário final e é falsificável por construção, então o pior desfecho possível é `review`: não existe caminho de recusa automática neste módulo, em nenhuma severidade e com nenhuma calibração. **E este evento não substitui a verificação de onboarding**: se o seu sistema guarda "a última verificação por `reference_id`", use o `kind` para não sobrescrever o resultado do KYC com um alerta de sessão.

**O que nunca sai no payload:** a coordenada (o que viaja é distância, intervalo e velocidade implícita), o endereço de rede e o identificador do aparelho: os dois só existem no nosso banco como derivados por chave secreta, e devolvê-los serviria apenas para alguém testar palpites contra eles.

**Não confunda com o `monitoring_aml`**, que reconsulta listas de compliance sobre a **pessoa** e cobra por mês. Este observa **uma sessão** no tempo e cobra por achado.