> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devmob.app.br/llms.txt
> Use this file to discover all available pages before exploring further.

# audit_log.requested

> Evento audit-ready consumido por Observability para persistir um AuditLog

`audit_log.requested` é emitido depois que uma mutação auditável termina com
sucesso. O evento transporta todos os dados necessários para criar um
[AuditLog](/data-modelling/observability/audit-log) sem consultar novamente o
domínio de origem.

## Detalhes do Evento

| Propriedade    | Valor                                                          |
| -------------- | -------------------------------------------------------------- |
| **Tipo**       | `audit_log.requested`                                          |
| **Origem**     | Services de mutação, schedulers e integrações                  |
| **Publicação** | Depois do sucesso da operação principal                        |
| **Quando**     | Sempre que uma mutação documentada precisar de rastreabilidade |

## Handlers

| Handler          | Responsabilidade                  | Dados usados         | Execução    |
| ---------------- | --------------------------------- | -------------------- | ----------- |
| `recordAuditLog` | Persiste um registro append-only. | `identifier`, `data` | Assíncrona. |

## Payload

| Campo        | Tipo                  | Descrição                                                                       |
| ------------ | --------------------- | ------------------------------------------------------------------------------- |
| `identifier` | `UUID`                | Identificador único da mutação; torna o consumo idempotente e vira `auditLogId` |
| `data`       | `RecordAuditLogInput` | Campos completos do AuditLog, sem `auditLogId` e `createdAt`                    |

## Regras dos handlers

* O produtor envia snapshots, ator, organização, IP e User-Agent; o handler não
  consulta o domínio de origem.
* O handler persiste exatamente um registro append-only por `identifier`.
* Falha no handler não desfaz a mutação que publicou o evento.
* Redelivery com o mesmo `identifier` devolve o registro já persistido sem
  criar duplicata.
* Mutações diferentes do mesmo recurso usam identificadores diferentes.
* Eventos de scheduler ou integração usam `SYSTEM_LOG` e podem omitir o ator.

## Exemplo

```json theme={null}
{
  "type": "audit_log.requested",
  "identifier": "0197a819-ae6c-7cd6-b872-1f6c898c50d9",
  "data": {
    "organizationId": "0197a801-6a42-79aa-9e56-d3c85148c0fa",
    "userId": "0197a805-0910-7eb2-bae7-90a13df2a9b2",
    "type": "APPLICATION_LOG",
    "domain": "OPERATIONS",
    "resource": "ROUTE",
    "resourceId": "0197a80c-4204-7b77-9005-48cc23677587",
    "action": "ROUTE_APPROVED",
    "userAgent": "DEVMOB-Ops/1.0",
    "ip": "203.0.113.10",
    "oldData": {
      "status": "PENDING_APPROVAL"
    },
    "newData": {
      "status": "ACTIVE"
    },
    "createdBy": "0197a805-0910-7eb2-bae7-90a13df2a9b2"
  }
}
```