Usando os registros de auditoria

Toda requisição de API na sua organização é registrada por 365 dias - quem, o quê, quando, de onde e sob qual aplicação. É o primeiro lugar para olhar quando você precisa saber o que aconteceu.

Escrito pelo suporte da Didit · Atualizado em 19 de agosto de 2026

#O que é registrado

1234

1. Filtre por membro, caminho, método ou data para responder 'quem alterou isso'.
2. Method e status distinguem uma leitura de uma mudança que realmente teve efeito.
3. O membro que fez a chamada.
4. De onde ela veio - o detalhe que transforma um registro em evidência.

Toda requisição feita à plataforma Didit dentro da sua organização, seja qual for a origem. Cada entrada traz:

Os registros são mantidos por 365 dias e depois excluídos automaticamente.

#Para que ele realmente serve

Quatro situações em que é a ferramenta certa:

• "Quem alterou este fluxo de trabalho?" Um fluxo se comportando de forma diferente de ontem geralmente tem uma edição por trás, e o registro mostra quem a fez.
• Investigando um incidente. Rastrear exatamente o que foi acessado, por quem, a partir de qual endereço, em qual ordem.
• Depurando uma integração. Ver as requisições que o seu próprio código realmente fez, em vez das que você acredita que fez - inclusive as que retornaram 4xx.
• Evidenciando o controle de acesso. Mostrar a um auditor que o acesso a dados de verificação é atribuído e revisável.

#Filtrando

Filtre por usuário, endpoint ou intervalo de datas para reduzir uma lista longa. Ao investigar algo específico, comece pelo carimbo de data/hora e vá se afastando dali - uma requisição raramente acontece sozinha, e as chamadas ao redor dela geralmente contam a história.

#Requisições com chave de API são atribuídas à aplicação, não a uma pessoa

Uma requisição com chave de API não tem um usuário a quem atribuí-la, então ela aparece contra a aplicação. Essa é a representação honesta - a plataforma genuinamente não sabe qual dos seus serviços ou engenheiros fez a chamada.

A consequência prática: uma única chave compartilhada entre vários serviços torna um incidente consideravelmente mais difícil de investigar. Se a atribuição importa para você, dê a cada consumidor sua própria aplicação e chave.

#O que está no registro, e o que não está

O registro guarda atividade - quem chamou o quê, quando, de onde e qual status voltou. É uma trilha de metadados, não uma cópia dos dados de verificação.

Se você precisa saber se dados pessoais de clientes aparecem nessas entradas - uma pergunta comum durante revisões de proteção de dados - obtenha a resposta com o seu contato na Didit e registre-a, em vez de deduzi-la de uma página de ajuda. É exatamente o tipo de afirmação que a sua própria AIPD (avaliação de impacto à proteção de dados) vai precisar comprovar.

#Quem pode ver

O acesso aos registros de auditoria segue a função de cada pessoa. Responsável pela Conformidade inclui esse acesso; Leitor não tem acesso amplo. Proprietários podem concedê-lo a uma função personalizada. Veja como convidar membros da equipe e definir funções.

Remover um colega não remove o histórico dele do registro - e esse é o objetivo. Uma trilha que você pode editar não é uma trilha.

#Exportações e relatórios também são registrados

Gerar um PDF de sessão ou uma exportação CSV é uma chamada de API, então ela aparece aqui com quem a fez. Isso é útil quando você precisa mostrar que o acesso a evidências de verificação é controlado, e não livre. Veja como baixar um relatório de verificação.

#Se você precisa de mais de 365 dias

A retenção é fixa em 365 dias. Se a sua obrigação exige um período maior, exporte o que você precisa periodicamente e guarde no seu próprio sistema - o mesmo padrão de reter evidências de sessão por conta própria. Decidir o período exigido é uma decisão de conformidade da sua equipe; não planeje em cima de uma suposição.