La rotation régulière des clés API est une bonne pratique de sécurité essentielle. L'endpoint POST /v1/api-keys/{id}/rotate génère une nouvelle clé avec exactement les mêmes scopes, liste d'IP autorisées et environnement que la clé source, puis place l'ancienne clé en révocation différée. Pendant la fenêtre de grâce (7 jours par défaut, 0 à 30 jours au choix), les deux clés restent actives simultanément : vous pouvez déployer la nouvelle valeur dans vos systèmes sans jamais couper le flux. À l'expiration de la fenêtre, un cron quotidien révoque automatiquement l'ancienne clé et déclenche l'événement api_key.rotated.
/v1/api-keys/{id}/rotateRotation atomique d'une clé API : crée une nouvelle clé identique et planifie la révocation de l'ancienne après la fenêtre de grâce.GET/v1/api-keys/{id}Récupère les détails d'une clé (dont `scheduled_revoke_at`, `rotated_from_id`, `rotated_to_id`) pour vérifier l'état après rotation.Authentification
Les deux endpoints exigent le scope api_keys:manage. Ce scope est considéré comme sensible : il ne peut pas être accordé à une clé de type restricted (préfixe cof_rk_live_… ou cof_rk_test_…). Pour appeler ces routes, vous devez utiliser une clé full-power (cof_live_… ou cof_test_…) ou une clé restricted qui possède explicitement api_keys:manage, ce qui est impossible par construction. Transmettez votre clé dans l'en-tête Authorization: Bearer <votre-clé>.
Corps de la requête
Le corps précise surtout la fenêtre de grâce (grace_days) pendant laquelle l'ancienne clé reste valide. Le tableau ci-dessous détaille les champs acceptés.
| Champ | Type | Requis | Description |
|---|---|---|---|
| grace_days | integer | Non | Nombre de jours pendant lesquels l'ancienne clé reste active après la rotation. Défaut : 7. Min : 0 (révocation immédiate). Max : 30. |
Exemples d'appel
L'exemple ci-dessous effectue une rotation avec une fenêtre de grâce, puis vérifie l'état de l'ancienne clé. Choisissez votre langage.
Réponse (HTTP 201)
La réponse renvoie la nouvelle clé en clair (new_key), affichée une seule et unique fois : stockez-la immédiatement. Elle expose aussi l'échéance de révocation de l'ancienne clé.
Erreurs
Les erreurs portent sur le scope api_keys:manage manquant, une clé introuvable ou déjà en rotation. Le tableau ci-dessous indique la résolution.
| HTTP | Code | Quand | Résolution |
|---|---|---|---|
| 401 | missing_api_key | Aucun header Authorization fourni. | Ajoutez Authorization: Bearer cof_live_… à la requête. |
| 401 | invalid_api_key | La clé Bearer est mal formée ou inconnue. | Vérifiez que vous utilisez la valeur complète retournée à la création. |
| 401 | revoked_api_key | La clé appelante a déjà été révoquée. | Utilisez une clé active pour effectuer la rotation. |
| 403 | scope_missing | La clé appelante ne possède pas le scope api_keys:manage. | Utilisez une clé full-power (cof_live_… ou cof_test_…). |
| 403 | ip_not_allowed | L'IP de la requête n'est pas dans la liste allowed_ips de la clé appelante. | Lancez la requête depuis une IP autorisée ou retirez la restriction. |
| 404 | not_found | L'identifiant {id} ne correspond à aucune clé de ce workspace. | Vérifiez l'ID dans le dashboard ou via GET /v1/api-keys. |
| 429 | rate_limited | Quota de requêtes d'écriture dépassé pour ce workspace. | Attendez la durée indiquée dans Retry-After avant de réessayer. |
| 500 | internal_error | Erreur interne lors de la création ou de la planification. | Réessayez. Si le problème persiste, contactez le support avec le X-Request-Id. |
Bonnes pratiques
Vérifier l'état de l'ancienne clé
Après la rotation, vous pouvez inspecter l'ancienne clé via GET /v1/api-keys/{old_id}. Les champs scheduled_revoke_at, rotated_to_id et is_active reflètent l'état en temps réel. Tant que is_active vaut true et que revoked_at est null, l'ancienne clé continue d'accepter les requêtes.
Voir aussi
- Créer une clé API
- Révoquer une clé API
- Comprendre les scopes API
- Recevoir des événements via Webhook
- Référence : api_key.rotated