Authentification
L’API Sangho utilise des clés API pour authentifier les requêtes. Chaque App dispose d’une clé publique et d’une clé secrète.
Types de clés
| Type | Préfixe (prod) | Préfixe (test) | Usage |
|---|---|---|---|
| Clé Publique | pk_prod_ | pk_test_ | Initialisation SDK côté client uniquement |
| Clé Secrète | sk_prod_ | sk_test_ | Requêtes serveur uniquement — ne jamais exposer |
L’environnement s’appelle prod, pas live — la clé sk_prod_ est la seule à déclencher des transactions réelles.
Utilisation en header HTTP
Ajoutez votre clé secrète dans le header Authorization de chaque requête, préfixée par Bearer.
Sandbox vs. Production
Les clés sk_test_ pointent vers la base Sandbox — aucune transaction réelle. Les clés sk_prod_ déclenchent des transactions réelles.
Ne jamais utiliser une clé sk_prod_ en frontend ou dans du code JavaScript côté client. Elle pourrait être exposée et compromise.
Rotation de clés
- 1. Créez une nouvelle clé depuis Dashboard → Paramètres → Clés API
- 2. Mettez à jour votre configuration serveur avec la nouvelle clé
- 3. Révoquez l’ancienne clé — elle est immédiatement invalidée
- 4. Toutes les requêtes avec l’ancienne clé retourneront 401
Idempotency Key
Pour les requêtes POST critiques (PaymentIntent, Refund), ajoutez un header Idempotency-Key unique — un UUID par exemple. Si vous re-soumettez la même requête avec la même clé dans les 24h, Sangho retourne la réponse déjà produite (avec l’en-tête Idempotency-Replayed: true) au lieu de créer un doublon.
Si la même clé est réutilisée avec un corps de requête différent, Sangho refuse la requête avec une erreur 409 IDEMPOTENCY_CONFLICT plutôt que de deviner quelle version traiter.
Header d’authentification
Avec Idempotency Key
Exemple d’appel authentifié
Réponse — Clé invalide (401)
Récupérez vos clés depuis Dashboard → Développeurs → Clés API. Les clés test sont visibles dès l’inscription, sans KYC requis.