> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Registros de auditoría: actividad de API y cumplimiento > Didit guarda la actividad de la API en registros de auditoría. Filtra por usuario, método, estado y fecha para auditorías, seguridad y depuración. Los registros de auditoría ofrecen un historial completo y consultable de toda la actividad de la API en tu organización. Cada solicitud a la plataforma Didit, ya venga de la Console, de tu integración o de los miembros de tu equipo, se registra automáticamente con fines de seguridad, cumplimiento normativo y resolución de problemas. ![Registros de auditoría en la consola de Didit](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-audit-logs.jpg?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=bcd436f764486143268f5c5ca67d9d14) *** ## Por qué usar registros de auditoría | Reto | Solución | | - | - | | Requisitos de cumplimiento normativo | Registro de auditoría completo de toda la actividad, hasta donde lo conserve tu plan | | Investigación de incidentes de seguridad | Rastrea con exactitud quién hizo qué y cuándo | | Depuración de problemas de integración | Consulta la ruta, el estado y el cuerpo con datos ocultos de cada solicitud | | Rendición de cuentas del equipo | Controla a qué datos accedió cada miembro del equipo | | Supervisión del uso | Entiende los patrones de consumo de la API | *** ## Acceso a los registros de auditoría Abre **Settings > Organization > Audit log** en la consola de Didit. La interfaz muestra una lista cronológica de todas las solicitudes a la API realizadas en tu organización. Cada entrada del registro incluye: | Campo | Descripción | | - | - | | **Sello de tiempo** | Cuándo se hizo la solicitud | | **Usuario** | Quién la hizo: el correo electrónico del miembro del equipo autenticado; el nombre de la clave de API que hizo la solicitud, con la etiqueta **API key**; o **The Investigator**, en el caso de una decisión que tomó por su cuenta | | **Método** | Método HTTP (GET, POST, PUT, DELETE) | | **Ruta** | El endpoint de la API que se invocó | | **Estado** | Código de estado de la respuesta HTTP | | **Dirección IP** | IP de origen de la solicitud | | **Aplicación** | La aplicación a la que se asoció la solicitud | ### Decisiones tomadas por el Investigator Cada decisión que el [Investigator](https://docs.didit.me/es/console/investigator.md) toma por su cuenta se registra bajo **The Investigator**, no bajo un miembro ni una clave de API: aprobar o rechazar una sesión o solicitar un nuevo envío, fijar el estado de una transacción, y resolver un caso, escalarlo o solicitar información sobre él. La entrada enlaza al informe del Investigator en el que se basa la decisión. Cuando una persona acepta o anula una recomendación del Investigator, la entrada se registra bajo esa persona. *** ## Filtros y búsqueda La interfaz de los registros de auditoría ofrece potentes opciones de filtrado para que encuentres exactamente lo que buscas. ### Búsqueda inteligente La barra de búsqueda detecta automáticamente lo que buscas: | Tipo de búsqueda | Ejemplo | Comportamiento | | - | - | - | | **Ruta exacta** | `/v1/organization/.../sessions/` | Encuentra los registros con esta ruta de solicitud exacta | | **Correo electrónico exacto** | `admin@company.com` | Encuentra los registros de este usuario concreto | | **IP exacta** | `192.168.1.100` | Encuentra los registros de esta dirección IP | | **Comodín** | `/v1/*/analytics/*` | Coincide con patrones que usan comodines | | **Texto general** | `sessions` | Búsqueda aproximada en todos los campos | ### Filtros disponibles | Filtro | Descripción | Ejemplo | | - | - | - | | **Aplicación** | Filtra por una aplicación concreta | Selecciónala en el menú desplegable | | **Miembros y claves de API** | Filtra por la clave de API que hizo las solicitudes | Selecciona una clave de la aplicación elegida | | **Actor** | Muestra solo lo que hicieron los miembros, las claves de API o The Investigator | **The Investigator** | | **Método** | Filtra por método HTTP | `GET`, `POST`, `PUT`, `DELETE` | | **Código de estado** | Filtra por estado de la respuesta | `200`, `401`, `500` | | **Rango de fechas** | Filtra por periodo de tiempo | Últimos 7 días, rango personalizado | *** ## Retención de datos Tu plan determina hasta qué fecha puedes consultar el registro de auditoría y si puedes exportarlo: | Plan | Antigüedad | Exportación | | - | - | - | | Free | 30 días | No | | Growth | 1 año | No | | Scale | 3 años | Sí | | Enterprise | Según tu contrato | Sí | Una exportación en un plan que no la incluye devuelve un `403` con `"code": "plan_limit_exceeded"`. *** ## Seguridad y privacidad ### Qué se registra Los registros de auditoría recogen metadatos de las solicitudes a la API: * Sello de tiempo y duración de la solicitud * Identidad del usuario (correo electrónico, ID de usuario) o la clave de API que hizo la solicitud (su nombre y los primeros caracteres de su secreto, nunca el secreto completo) * Ruta de la solicitud y parámetros de consulta * Códigos de estado de la respuesta * Dirección IP y user agent del cliente ### Cuerpos de solicitud y respuesta de las llamadas con clave de API En una solicitud realizada con una clave de API, el registro de auditoría también conserva una copia censurada del cuerpo JSON de la solicitud de una escritura y de la respuesta a una escritura o a un error, para que puedas ver por qué falló una solicitud. La respuesta a una solicitud de lectura exitosa no se conserva. La censura utiliza un enfoque de denegación predeterminada: * La estructura se mantiene: nombres de campos, anidamiento, tipos de valores, longitudes de arrays y longitudes de cadenas. * Un valor solo se mantiene cuando es uno de los identificadores, estados, códigos, recuentos o sellos de tiempo propios de Didit, en un campo que Didit define y con la estructura que ese campo espera. * Un booleano solo se mantiene en un campo que Didit define. * Cualquier otro valor se sustituye por un marcador que indica su tipo y longitud, como `[redacted:string:12]`, `[redacted:number:5]` o `[redacted:boolean]`, y `null` se mantiene como `null`. * Un nombre de campo que no es un identificador simple, como una dirección de correo electrónico o un número de teléfono usado como clave, se sustituye por `[redacted:key:23]`. * Un cuerpo que no es JSON, como un formulario o la subida de un archivo, se sustituye por una nota que indica qué era. * El contenido restante se trunca a 4096 caracteres. Los parámetros de consulta pasan por la misma censura. Solo se conservan los encabezados estándar, como `content-type`, `user-agent` y los encabezados de límite de solicitudes; cualquier otro encabezado se descarta junto con su valor. Un valor que envía tu propio sistema, por ejemplo en `metadata` o `vendor_data`, nunca se conserva, aunque su campo se llame como uno de los de Didit. ### Qué NO se registra Para proteger los datos sensibles, se excluye automáticamente lo siguiente: * Tokens de autenticación y credenciales * Contraseñas y secretos * Datos personales de las sesiones de verificación ### Control de acceso Para ver el registro de auditoría se necesitan los permisos de lectura y listado de `audit-logs`. Los roles Lector, Responsable de cumplimiento, Desarrollador, Administrador y Propietario los tienen, y un [rol personalizado](https://docs.didit.me/es/console/roles-permissions.md) los obtiene al seleccionar Audit logs en el editor de roles. *** ## Casos de uso habituales > [accordion] Auditorías de cumplimiento > > Demuestra a los auditores que tienes visibilidad completa sobre quién accedió a los datos de verificación: > > 1. Filtra por el rango de fechas que coincida con el periodo de auditoría > 2. Filtra por aplicaciones o usuarios concretos si es necesario > 3. Exporta los resultados o haz capturas de pantalla para la documentación > [accordion] Investigación de seguridad > > Si sospechas de un acceso no autorizado: > > 1. Busca el correo electrónico del usuario afectado o las direcciones IP sospechosas > 2. Filtra por un rango de fechas en torno al incidente sospechado > 3. Busca patrones inusuales: intentos de autenticación fallidos, endpoints inesperados, horarios anómalos > [accordion] Depuración de la integración > > Al resolver problemas de integración con la API: > > 1. Busca la ruta del endpoint concreto > 2. Filtra por códigos de estado `4xx` o `5xx` para encontrar errores > 3. Anota las marcas de tiempo para correlacionarlas con los registros de tu aplicación > [accordion] Revisión de la actividad del equipo > > Supervisa cómo usa la plataforma tu equipo: > > 1. Filtra por los correos electrónicos de miembros concretos del equipo > 2. Revisa a qué sesiones y funciones accedieron > 3. Asegúrate de que los miembros del equipo siguen los procedimientos adecuados *** ## Buenas prácticas 1. **Revisiones periódicas**: revisa los registros de auditoría de forma periódica para detectar anomalías a tiempo. 2. **Acota tu búsqueda**: usa filtros específicos para reducir el ruido y encontrar más rápido las entradas relevantes. 3. **Rangos de fechas**: especifica siempre un rango de fechas para obtener un mejor rendimiento con grandes volúmenes de datos. 4. **Guarda tus búsquedas**: guarda las combinaciones de filtros habituales como marcadores del navegador para acceder a ellas rápidamente. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.