> ## 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.

# Claves de API con permisos: acceso restringido a KYC

> Didit da a cada servicio o socio su clave de API con acceso mínimo: lectura o escritura por recurso, IP permitidas, caducidad y revocación inmediata.



Prompt de claves de API con alcance
        Copiar el prompt al portapapeles



      
      

\<pre>

\````# Goal - call Didit with a scoped API key

Every application has a primary secret with full access, and any number of named API keys.
A named key carries its own access: read or write per resource, optional limits, an optional IP allowlist and an optional expiry date.
Keys are created, edited, rotated and revoked in the Business Console (Developers -> API keys); there is no API to manage them.

\## Sending the key

\```bash
curl https://verification.didit.me/v3/session/$SESSION_ID/decision/ \
-H "x-api-key: $DIDIT_API_KEY"
\```

Read the key from an environment variable or a secrets manager, never from source code.

\## What each answer means

\| Status | Meaning |
\|---|---|
\| 401 | The key is missing, wrong, revoked or expired |
\| 403 | The key has no access to this resource or action, or the request came from an address outside its IP list |
\| 404 | The session is outside the key's workflows or statuses, so to this key it does not exist |

A key without media access receives decisions with every image, video and PDF URL set to null, and gets 403 on PDF reports.
A key without sessions write receives session_url and session_token as null.

\## Resources

sessions, decisions, media (read only), users, businesses, transactions, workflows, webhooks, applications, analytics (read only), api-keys.
Read covers GET requests, write covers POST, PUT, PATCH and DELETE.
Standalone checks (face match, ID verification, AML screening and the other /v3 standalone APIs) need sessions write.
Creating a person with send_verification_link: true (POST /v3/users/create/) needs users write and sessions write; without sessions write it answers 403 and nothing is created.

\## Limits

\- workflow_ids: only sessions of these workflows are visible, and sessions can only be created with them.
\- approved sessions only: declined, in-review and unfinished sessions are hidden.
\- A key with either limit cannot have access to users, businesses, transactions or analytics.

\## Rotation

Rotating a key returns a new secret once; the previous secret keeps working for 24 hours.````

\</pre>



      
      

Pegar en

Cada aplicación empieza con un **secreto principal** que tiene acceso completo a todo lo que la aplicación puede hacer.
Junto a él puedes añadir **claves de API con nombre**, una por servicio o socio, cada una con solo el acceso que necesita.
Dale a tu proveedor de pagos una clave que lea las sesiones aprobadas de un solo flujo y no pueda cambiar nada, mantén una clave aparte para tu backend y revoca cualquiera de las dos sin tocar la otra.> [!NOTE]
>
> Las claves creadas antes de que existiera el acceso con permisos específicos conservan el acceso completo.
> Nada cambia para ellas hasta que edites su acceso.***## Dónde encontrarlasEn la [**Business Console**](https://business.didit.me), selecciona tu aplicación y abre **Developers -> API keys**.La lista muestra todas las claves de la aplicación con su estado, sus solicitudes de los últimos 30 días, quién la creó, su acceso y cuándo se usó por última vez.
Haz clic en una clave para ver una vista previa a la derecha, o abre su página completa para ver el uso, el acceso, las solicitudes recientes, un fragmento de inicio rápido y su actividad.Las claves pertenecen a una aplicación y solo funcionan para ella.
Una clave tiene el entorno de la aplicación: las claves de una aplicación de sandbox nunca crean verificaciones facturadas.***## URL de redirección y dominios permitidosAbre **Developers > API keys > Redirects and domains** para configurar dos listas para la aplicación y el entorno que tengas seleccionados.| Lista | Qué controla |
| - | - |
| **URL de redirección** | Adónde envía Didit el navegador cuando termina una verificación alojada. Una URL debe coincidir exactamente, ruta incluida. |
| **Dominios permitidos** | Los orígenes (esquema, host y puerto opcional, como `https://app.example.com`) en los que se puede incrustar el flujo de verificación alojada y a los que puede devolver al usuario. |Cuando la lista de **Dominios permitidos** tiene entradas, [Crear sesión](https://docs.didit.me/es/sessions-api/create-session.md) rechaza con un error `400` un `callback` que no esté en ninguno de ellos.
Una lista vacía significa que no hay restricción.
Las llamadas de servidor a servidor no se ven afectadas.***## Crear una clave**1. Detalle**Ponle a la clave el nombre del servicio que la usará y elige cuándo caduca: nunca, en 30 días, en 90 días, en un año o en la fecha que elijas.
Una clave expirada deja de funcionar al final de ese día, en UTC.**2. Acceso**Parte de un acceso predefinido y ajústalo recurso por recurso.
La clave nunca podrá hacer más de lo que definas aquí.**3. Revisión**Antes de que la entregues, la consola detalla qué puede hacer la clave y qué no.**4. Clave secreta**Copia el secreto y guárdalo en tu gestor de secretos.
Es la única vez que se muestra el secreto completo.
Si lo pierdes, rota la clave para obtener uno nuevo.### Accesos predefinidos| Acceso predefinido | Acceso |
| - | - |
| **Acceso total** | Todos los recursos, en lectura y escritura, incluidas otras claves de API. Para tu propio backend. |
| **Solo lectura** | Sesiones y decisiones, con medios opcionales. No puede crear, modificar ni eliminar nada. Para un socio que necesita los resultados. |
| **Personalizado** | Eliges Ninguno, Lectura o Escritura para cada recurso. |### RecursosLa lectura cubre las solicitudes `GET` sobre un recurso; la escritura cubre además `POST`, `PUT`, `PATCH` y `DELETE`.| Recurso | Lectura | Escritura |
| - | - | - |
| **Sesiones** | Listar y abrir sesiones | Crear, actualizar y eliminar sesiones, importar sesiones y ejecutar comprobaciones independientes (coincidencia facial, verificación de identidad, análisis AML y las demás API independientes) |
| **Decisiones** | Resultados, puntuaciones de riesgo, datos extraídos e historial de análisis AML | Aprobar, rechazar o enviar a revisión, y cambiar los estados de las funciones y de las coincidencias AML |
| **Medios** | Imágenes de documentos de identidad, selfies, videos e informes en PDF | - |
| **Personas** (`users`) | Usuarios finales y todo lo verificado sobre ellos | Crear, actualizar y eliminar usuarios, y su monitorización. Crear un usuario con enlace de verificación también requiere escritura en **Sesiones** |
| **Empresas** (`businesses`) | Perfiles de empresas, sus documentos y sus propietarios | Crear, actualizar y eliminar empresas, y su monitorización |
| **Transacciones** | Transacciones, alertas, reglas, eventos de monitorización, datos de Travel Rule y análisis de wallets | Enviar transacciones y eventos, cambiar su estado y gestionar la configuración de Travel Rule, la libreta de direcciones de wallets y las transferencias |
| **Flujos de trabajo** | Flujos de verificación (workflows), cuestionarios, listas y listas de bloqueo | Crearlos y editarlos |
| **Webhooks** | Endpoints y entregas (con lectura en **Decisiones**, ya que una entrega contiene el payload de sesión enviado) | Añadir, editar y eliminar endpoints, y reenviar entregas |
| **Configuración de la aplicación** (`applications`) | Personalización y saldo | Cambiar la personalización y recargar el saldo |
| **Analíticas** | Métricas y exportaciones de informes | - |
| **Claves de API** | Reservado para la gestión de claves | Reservado para la gestión de claves |Una clave con acceso personalizado funciona en la API pública: los endpoints de sesiones, usuarios, empresas, transacciones, flujos y webhooks, y las comprobaciones independientes.
Los endpoints que solo usa la Business Console devuelven `403`; requieren una clave con acceso total.Una clave sin lectura en **Medios** recibe las decisiones de las sesiones con todas las URL de imágenes, videos y PDF establecidas en `null`, y los endpoints de informes en PDF responden `403`.
Una clave sin escritura en **Sesiones** nunca recibe el enlace de verificación ni el token de sesión de una sesión, ya que quien los tenga puede completar la verificación como si fuera el usuario final: esos campos se devuelven como `null`.
Por el mismo motivo, crear una persona con `send_verification_link: true` requiere escritura en **Sesiones** además de escritura en **Personas**, porque crea una sesión y envía su enlace por correo electrónico.
Sin ella, la solicitud devuelve `403` y no crea nada.### Límites| Límite | Qué hace |
| - | - |
| **Flujos de trabajo** | La clave solo ve las sesiones de los flujos que elijas y solo puede crear sesiones con ellos. Las solicitudes sobre cualquier otra sesión devuelven `404`, como si no existiera. |
| **Solo sesiones aprobadas** | Las sesiones rechazadas, en revisión y sin terminar quedan ocultas para la clave. |
| **Direcciones IP** | La clave solo funciona desde las direcciones o rangos CIDR que indiques (hasta 20, IPv4 o IPv6). Las solicitudes desde cualquier otra dirección devuelven `403`. |
| **Caduca** | Después de esta fecha, todas las solicitudes con la clave devuelven `401`. |Una clave limitada a algunos flujos o a sesiones aprobadas funciona en los endpoints de sesiones, donde se puede aplicar el límite.
No puede tener acceso a personas, empresas, transacciones ni analíticas, y no puede ejecutar comprobaciones independientes.***## Cómo responde la API a una clave con acceso limitado| Estado | Significado |
| - | - |
| **401** | La clave falta, es incorrecta, está revocada o ha expirado. |
| **403** | La clave no tiene acceso a este recurso o acción, o la solicitud provino de una dirección fuera de su lista de IP. |
| **404** | La sesión está fuera de los flujos o estados de la clave. |Las listas de sesiones solo devuelven las sesiones que permiten los límites de la clave.***## Editar accesoAbre el menú de una clave, su vista previa o su página y elige **Editar acceso**.
Cambia el acceso predefinido, los recursos, los límites o la caducidad y revisa únicamente los cambios antes y después de aplicarlos.
El secreto sigue siendo el mismo, así que no hace falta volver a desplegar nada, y el nuevo acceso se aplica en menos de un minuto.El secreto principal siempre tiene acceso total y no se puede editar.***## Rotar una claveAl rotar una clave se reemplaza su secreto.
El nuevo secreto se muestra una sola vez, y el secreto actual sigue funcionando durante **24 horas** para que puedas desplegar el nuevo sin tiempo de inactividad.
Después, todas las solicitudes con el secreto antiguo devuelven `401`.El secreto principal se rota de la misma forma, con el mismo periodo de solapamiento de 24 horas.***## Revocar una claveAl revocar una clave, deja de funcionar de inmediato: todas las solicitudes que se hagan con ella responden `401`.
No se puede deshacer.
El secreto principal no se puede revocar; rótelo en su lugar.***## Uso y registro de auditoríaCada clave muestra sus solicitudes de los últimos 30 días, su tasa de errores y su latencia, y sus solicitudes más recientes con sus códigos de estado, incluidas las que sus límites rechazaron.Cada llamada hecha con una clave de API aparece en los [registros de auditoría](https://docs.didit.me/es/console/audit-logs.md) de la organización con el nombre de la clave que realizó la llamada.***## Quién puede gestionar las clavesPara gestionar las claves de API se necesita el permiso **Claves de API**: lectura para verlas y escritura para crearlas, editarlas, rotarlas y revocarlas.
Consulta [Roles y permisos](https://docs.didit.me/es/console/roles-permissions.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.