Authentification et clés d'API

Vous authentifiez les requêtes API avec une clé secrète. Envoyez-la comme jeton bearer dans l'en-tête Authorization.

curl https://api.abuna.app/v1/apps/8ddhXCDW/products \
  -H "Authorization: Bearer sk_test_..."

L'API lit aussi la clé dans un en-tête X-Api-Key. Elle ne vérifie cet en-tête que lorsque Authorization ne contient pas de jeton bearer.

Chaque POST accepte aussi un en-tête Idempotency-Key, pour que vous puissiez le réessayer sans risque. Voir Requêtes idempotentes.

curl https://api.abuna.app/v1/apps/8ddhXCDW/products \
  -H "X-Api-Key: sk_test_..."

Clés secrètes

Une clé secrète est sk_test_ ou sk_live_ suivi de 48 caractères hexadécimaux. Chaque clé appartient à un ID d'application dans un mode. L'ID d'application dans le chemin doit correspondre à l'application de la clé, une clé Test ne peut donc pas atteindre les données Réelles.

Abuna affiche votre première clé Test et votre clé Réelle une seule fois, à la création de l'application. Pour ajouter une clé, ouvrez Paramètres, puis Clés d'API. Une application peut avoir plusieurs clés actives, vous pouvez donc passer à une nouvelle clé avant de révoquer l'ancienne. Seuls les propriétaires d'équipe peuvent créer ou révoquer des clés.

Ce qu'une clé secrète peut faire

Une clé secrète fonctionne sur chaque endpoint /v1/apps/{appID}/... de son application, à ces exceptions près. Elles exigent une connexion au tableau de bord, une clé divulguée ne peut donc pas prendre le contrôle de votre application :

• Modifier les réglages de l'application, y compris l'URL de webhook
• Lister, créer ou révoquer des clés d'API
• Renouveler la clé publiable ou le secret de signature du webhook
• Connecter, consulter ou déconnecter un prestataire de paiement

Une clé secrète qui appelle l'une d'elles reçoit 403 avec le code forbidden. Vous pouvez toujours lire l'application avec GET /v1/apps/{appID}, qui renvoie sa clé publiable.

Inversement, les sessions n'acceptent qu'une clé secrète. Une connexion au tableau de bord ou une clé publiable qui tente d'en créer, lister, lire ou expirer une reçoit 403 avec le code forbidden. Cela inclut POST /v1/apps/{appID}/sessions.

Clés publiables et secrets de signature de webhook

Chaque application possède aussi une clé publiable et un secret de signature de webhook. Ni l'une ni l'autre n'authentifie les requêtes API.

• La clé publiable (pk_test_ ou pk_live_) se place dans les liens de paiement, sous la forme publishkey=pk_test_.... Elle peut être montrée aux clients sans risque. La renouveler casse tous les liens de paiement qui portent l'ancienne clé.
• Le secret de signature de webhook (whsec_test_ ou whsec_live_) signe les webhooks qu'Abuna vous envoie. Gardez-le sur votre serveur. Voir Recevoir des webhooks.

Chacun est son préfixe suivi de 48 caractères hexadécimaux.

Échec d'authentification

• Une clé absente, révoquée ou incorrecte renvoie 401 avec le code unauthenticated.
• Une clé valide pour une autre application, ou un ID d'application qui n'existe pas, renvoie 404 avec le code not_found.
• Une application Réelle dont le propriétaire d'équipe n'a pas vérifié son e-mail renvoie 403 avec le code email_unverified.