Passer au contenu principal
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.
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 trouver

Dans la Console Business, 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és

Ouvrez Développeurs > Clés API > Redirections et domaines pour définir deux listes pour l’application et l’environnement sélectionnés. Lorsque la liste Domaines autorisés contient des entrées, Créer une session 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

​
Ressources

La lecture couvre les requêtes GET sur une ressource ; l’écriture couvre aussi POST, PUT, PATCH et DELETE. 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

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

Les listes de sessions ne renvoient que les sessions autorisées par les limites de la clé.

​
Modifier l’accès

Ouvrez 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’audit

Chaque 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 de l’organisation, avec le nom de la clé qui l’a effectué.

​
Qui peut gérer les clés

La 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.
Dernière modification le 7 novembre 2026