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

# Clés API restreintes : accès limité à l'API Didit

> Clés API Didit dédiées par service ou partenaire, avec accès restreint : lecture/écriture par ressource, liste IP, expiration et révocation immédiate.



Invite relative aux clés API à portée limitée
        Copier le prompt dans le presse-papiers



      
      

\<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>



      
      

Coller dans

Chaque application commence avec un **secret principal** qui a un accès complet à tout ce que l'application peut faire.
Vous pouvez ajouter à côté des **clés API nommées**, une par service ou par partenaire, chacune avec uniquement l'accès dont elle a besoin.
Donnez à votre prestataire de paiement une clé qui lit les sessions approuvées d'un seul workflow et ne peut rien modifier, gardez une clé distincte pour votre backend, et révoquez l'une ou l'autre sans toucher à la seconde.> [!NOTE]
>
> Les clés créées avant l'introduction de l'accès limité conservent un accès complet.
> Rien ne change pour elles tant que vous ne modifiez pas leur accès.***## Où les trouverDans la [**Console Business**](https://business.didit.me), sélectionnez votre application et ouvrez **Développeurs -> Clés API**.La liste affiche chaque clé de l'application avec son statut, ses requêtes des 30 derniers jours, son créateur, son accès et la date de sa dernière utilisation.
Cliquez sur une clé pour l'aperçu à droite, ou ouvrez sa page complète pour consulter l'utilisation, l'accès, les requêtes récentes, un extrait de démarrage rapide et son activité.Les clés appartiennent à une seule application et ne fonctionnent que pour elle.
Une clé suit l'environnement de son application : les clés d'une application sandbox ne créent jamais de vérifications facturées.***## URLs de redirection et domaines autorisésOuvrez **Développeurs > Clés API > Redirections et domaines** pour définir deux listes pour l'application et l'environnement sélectionnés.| Liste | Ce qu'elle contrôle |
| - | - |
| **URLs de redirection** | Où Didit renvoie le navigateur une fois la vérification hébergée terminée. Une URL doit correspondre exactement, chemin compris. |
| **Domaines autorisés** | Les origines (schéma, hôte et port facultatif, par exemple `https://app.example.com`) dans lesquelles le flux de vérification hébergé peut être intégré et vers lesquelles il peut renvoyer l'utilisateur. |Lorsque la liste **Domaines autorisés** contient des entrées, [Créer une session](https://docs.didit.me/fr/sessions-api/create-session.md) rejette avec une erreur `400` tout `callback` qui ne figure sur aucune d'entre elles.
Une liste vide signifie qu'il n'y a aucune restriction.
Les appels serveur à serveur ne sont pas concernés.***## Créer une clé**1. Détails**Nommez la clé d'après le service qui l'utilisera, et choisissez son échéance : jamais, dans 30 jours, dans 90 jours, dans un an, ou à une date de votre choix.
Une clé expirée cesse de fonctionner à la fin de cette journée, en UTC.**2. Accès**Partez d'un préréglage, puis affinez-le ressource par ressource.
La clé ne peut jamais faire plus que cela.**3. Contrôle**La console détaille ce que la clé peut faire et ce qu'elle ne peut pas faire, avant que vous ne la remettiez.**4. Clé secrète**Copiez le secret et conservez-le dans votre gestionnaire de secrets.
C'est la seule fois où le secret complet est affiché.
Si vous le perdez, effectuez une rotation de la clé pour en obtenir une nouvelle.### Préréglages| Préréglage | Accès |
| - | - |
| **Accès complet** | Toutes les ressources, en lecture et en écriture, y compris les autres clés API. Pour votre propre backend. |
| **Lecture seule** | Sessions et décisions, avec médias en option. Elle ne peut rien créer, modifier ni supprimer. Pour un partenaire qui a besoin des résultats. |
| **Personnalisé** | Vous choisissez Aucun, Lecture ou Écriture pour chaque ressource. |### RessourcesLa lecture couvre les requêtes `GET` sur une ressource ; l'écriture couvre aussi `POST`, `PUT`, `PATCH` et `DELETE`.| Ressource | Lecture | Écriture |
| - | - | - |
| **Sessions** | Lister et ouvrir les sessions | Créer, mettre à jour et supprimer des sessions, importer des sessions, et lancer des vérifications autonomes (correspondance faciale, vérification d'identité, filtrage AML et les autres API autonomes) |
| **Décisions** | Résultats, scores de risque, données extraites et historique de filtrage AML | Approuver, refuser ou envoyer en examen, et modifier les statuts des fonctionnalités et des correspondances AML |
| **Médias** | Images de pièces d'identité, selfies, vidéos et rapports PDF | - |
| **Personnes** (`users`) | Utilisateurs finaux et toutes les informations vérifiées les concernant | Créer, mettre à jour et supprimer des utilisateurs, ainsi que leur surveillance. Créer un utilisateur avec un lien de vérification nécessite aussi l'écriture sur **Sessions** |
| **Entreprises** (`businesses`) | Profils d'entreprises, leurs documents et leurs propriétaires | Créer, mettre à jour et supprimer des entreprises, ainsi que leur surveillance |
| **Transactions** | Transactions, alertes, règles, événements de surveillance, données Travel Rule et filtrage des portefeuilles | Envoyer des transactions et des événements, modifier leur statut, et gérer les paramètres Travel Rule, le carnet d'adresses des portefeuilles et les transferts |
| **Workflows** | Workflows, questionnaires, listes et listes de blocage | Créer et modifier ces éléments |
| **Webhooks** | Endpoints, et livraisons (avec la lecture de **Décisions**, puisqu'une livraison contient la charge utile de session envoyée) | Ajouter, modifier et supprimer des endpoints, et renvoyer des livraisons |
| **Paramètres de l'application** (`applications`) | Personnalisation et solde | Modifier la personnalisation et recharger le solde |
| **Analyses** | Métriques et exports de rapports | - |
| **Clés API** | Réservé à la gestion des clés | Réservé à la gestion des clés |Une clé à accès personnalisé fonctionne sur l'API publique : les endpoints de session, d'utilisateur, d'entreprise, de transaction, de workflow et de webhook, ainsi que les vérifications autonomes.
Les endpoints que seule la Business Console utilise répondent `403` à cette clé ; ils nécessitent une clé à accès complet.Une clé sans lecture de **Médias** reçoit les décisions de session avec chaque URL d'image, de vidéo et de PDF définie à `null`, et les endpoints de rapports PDF répondent `403`.
Une clé sans écriture de **Sessions** ne reçoit jamais le lien de vérification ni le token de session d'une session, car quiconque les détient peut effectuer la vérification à la place de l'utilisateur final : ces champs sont renvoyés à `null`.
Pour la même raison, créer une personne avec `send_verification_link: true` nécessite l'écriture sur **Sessions** en plus de l'écriture sur **Personnes**, car cela crée une session et envoie son lien par e-mail.
Sans cela, l'appel répond `403` et ne crée rien.### Limites| Limite | Effet |
| - | - |
| **Workflows** | La clé ne voit que les sessions des workflows que vous choisissez, et ne peut créer des sessions qu'avec eux. Toute autre session répond `404`, comme si elle n'existait pas. |
| **Sessions approuvées uniquement** | Les sessions refusées, en cours d'examen et inachevées restent masquées pour la clé. |
| **Adresses IP** | La clé ne fonctionne qu'à partir des adresses ou plages CIDR que vous indiquez (jusqu'à 20, IPv4 ou IPv6). Les requêtes provenant de toute autre adresse répondent `403`. |
| **Expiration** | Après cette date, chaque requête faite avec la clé répond `401`. |Une clé limitée à certains workflows ou aux sessions approuvées fonctionne sur les endpoints de session, là où la limite peut être appliquée.
Elle ne peut pas accéder aux personnes, aux entreprises, aux transactions ni aux analyses, et elle ne peut pas lancer de vérifications autonomes.***## Comment l'API répond à une clé limitée| Statut | Signification |
| - | - |
| **401** | La clé est absente, incorrecte, révoquée ou expirée. |
| **403** | La clé n'a pas accès à cette ressource ou à cette action, ou la requête provient d'une adresse qui ne figure pas dans sa liste d'adresses IP. |
| **404** | La session se trouve en dehors des workflows ou des statuts de la clé. |Les listes de sessions ne renvoient que les sessions autorisées par les limites de la clé.***## Modifier l'accèsOuvrez le menu d'une clé, son aperçu ou sa page, et choisissez **Modifier l'accès**.
Modifiez le préréglage, les ressources, les limites ou l'expiration, puis vérifiez uniquement ce qui change, avant et après.
Le secret reste le même, donc aucun redéploiement n'est nécessaire, et le nouvel accès s'applique en moins d'une minute.Le secret principal dispose toujours d'un accès complet et ne peut pas être modifié.***## Effectuer la rotation d'une cléLa rotation remplace le secret d'une clé.
Le nouveau secret est affiché une seule fois, et le secret actuel continue de fonctionner pendant **24 heures** afin que vous puissiez déployer le nouveau sans interruption.
Ensuite, chaque requête faite avec l'ancien secret répond `401`.Le secret principal fait l'objet d'une rotation de la même manière, avec le même chevauchement de 24 heures.***## Révoquer une cléLa révocation arrête une clé immédiatement : chaque requête faite avec elle répond `401`.
Cette action est irréversible.
Le secret principal ne peut pas être révoqué ; effectuez plutôt une rotation.***## Utilisation et piste d'auditChaque clé affiche ses requêtes sur les 30 derniers jours, son taux d'erreur et sa latence, ainsi que ses dernières requêtes avec leurs codes de statut, y compris celles que ses limites ont refusées.Chaque appel effectué avec une clé API apparaît dans les [journaux d'audit](https://docs.didit.me/fr/console/audit-logs.md) de l'organisation, avec le nom de la clé qui l'a effectué.***## Qui peut gérer les clésLa gestion des clés API nécessite l'autorisation **Clés API** : lecture pour les consulter, écriture pour les créer, les modifier, les renouveler et les révoquer.
Consultez [Rôles et autorisations](https://docs.didit.me/fr/console/roles-permissions.md).


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