Transmettre la clé
Toutes les requêtes exigent une clé API, dans l’en-têteAuthorization :
x-api-key: 0flaw_live_xxxxxxxx est accepté en alternative, pour les clients qui
réservent Authorization à autre chose.
Cloisonnement
Une clé est rattachée à une seule entreprise. Elle ne peut, par construction, ni lire ni
modifier les données d’une autre. Vous ne passerez jamais d’identifiant d’entreprise en
paramètre : il est déduit de la clé.
Permissions
Chaque clé porte des permissions explicites, choisies à sa création. Un appel sans la permission requise renvoie403 avec le code INSUFFICIENT_SCOPE et le scope manquant dans la réponse :
D’autres permissions (lecture des résultats, des campagnes et des analytics) seront publiées en
même temps que les endpoints de lecture correspondants. Nous ne documentons que les permissions
réellement appliquées : vous faire créer une clé qui n’autoriserait rien serait trompeur.
Bonnes pratiques
Une clé par intégration
Une clé par intégration
Créez une clé distincte par système connecté (SIRH, SIEM, script interne). En cas de fuite ou
de départ d’un prestataire, vous révoquez la clé concernée sans interrompre les autres.
Ne la stockez jamais dans le code
Ne la stockez jamais dans le code
Passez par une variable d’environnement ou un gestionnaire de secrets. Une clé commitée dans un
dépôt git reste dans l’historique même après suppression du fichier.
Révoquez au moindre doute
Révoquez au moindre doute
La révocation est immédiate et sans effet de bord : les appels suivants reçoivent
401 API_KEY_INVALID. Créer une nouvelle clé prend dix secondes.Limites de débit
600 requêtes par tranche de 15 minutes et par clé. Chaque réponse porteRateLimit-Limit,
RateLimit-Remaining et RateLimit-Reset : appuyez-vous sur ces en-têtes plutôt que d’attendre
le 429.