Authentification

Le header

Authorization: Bearer sk_live_…

C'est le seul mécanisme. Il n'existe aucun header X-API-Key — si votre intégration en envoie un, il est ignoré et la requête est rejetée en 401 UNAUTHORIZED.

Créer et révoquer une clé

Les clés se créent dans le tableau de bord az54. La gestion des clés n'est pas exposée à l'API : on ne crée ni ne révoque une clé par un appel HTTP.

Le secret n'est affiché qu'une seule fois, à la création. Il n'est stocké nulle part en clair côté az54 et ne peut pas être réaffiché. Stockez-le à ce moment-là.

Il n'y a ni rotation automatique, ni expiration. Une clé reste valide jusqu'à sa révocation — explicite, ou automatique si le membre qui l'a créée est retiré de l'équipe ou change de rôle. Émettez les clés d'intégration depuis un compte stable (l'owner).

En cas de fuite : créez la nouvelle clé d'abord, déployez-la, révoquez l'ancienne ensuite. Dans cet ordre — une révocation ne peut pas être annulée, et il n'existe pas de fenêtre de recouvrement.

Portée d'une clé

Une clé d'API authentifie une organisation entière, pas un utilisateur, mais elle reste rattachée au membre qui l'a créée (affiché dans l'écran Développeur) : son sort suit celui de ce membre. Il en découle trois propriétés qui surprennent souvent :

• Elle est soumise au même RBAC que le tableau de bord, mais par portées plutôt que par rôle : à la création, une clé reçoit un sous-ensemble attribuable des permissions du dashboard (PAYIN_INITIATE, PAYOUT_INITIATE, PAYOUT_APPROVE, TRANSACTIONS_VIEW, WEBHOOKS_MANAGE). Un appel qui touche une portée absente de la clé est refusé en 403 avec le code de la portée manquante (ex. PAYOUT_INITIATE_NOT_ALLOWED), pas un FORBIDDEN générique. La portée décide aussi du circuit d'approbation d'un payout : une clé avec PAYOUT_INITIATE sans PAYOUT_APPROVE dépose un brouillon pending_approval, exactement comme un rôle accountant du tableau de bord — voir Verser.
• Elle contourne l'authentification à deux facteurs, y compris sur les chemins qui l'exigent d'un utilisateur du tableau de bord : une clé n'a pas d'utilisateur associé, donc pas de second facteur à vérifier.
• Toute transaction créée avec elle appartient à l'organisation, pas à un utilisateur nommé.

C'est un secret serveur. Il n'a rien à faire dans un client web ou une application mobile.

sk_test_ et sk_live_ appartiennent à des serveurs différents

Le préfixe n'est pas cosmétique : il décide du seul serveur où la clé fonctionne (401 sur l'autre). Voir la table des deux serveurs dans Démarrage, et le catalogue de résultats déterministes dans Numéros de test.

Le SDK JavaScript n'envoie aucune clé

@az54/core et @az54/react ne consomment que des endpoints publics (/v1/corridors/available, /v1/countries) : ils fonctionnent sans authentification et n'envoient jamais de clé.

Les champs publicKey (pk_live_…) et locale que leur documentation présente sont des vestiges sans effet : ils sont stockés dans la configuration du client et jamais utilisés. Il n'existe aucun préfixe pk_ côté serveur. Ne construisez rien dessus.

@az54/core en version 0.3.0 ou antérieure lit par ailleurs un champ code sur les réponses d'erreur, qui n'est jamais présent : le vrai code machine-lisible est status (voir Erreurs).