Devin fournit plusieurs versions d’API avec différents mécanismes d’authentification et modèles d’autorisation. Comprendre quel type d’API key utiliser est essentiel pour une intégration réussie.
Récapitulatif des versions de l’API
| Version | Authentification | Modèle d’autorisation |
|---|
| v1 | Clés d’API personnelles ou de service | Portée à l’organisation |
| v2 | Clés d’API personnelles | Administrateurs Enterprise uniquement |
| v3 (Beta) | Identifiants d’utilisateur de service | RBAC complet |
Types de clés d’API
| Type de clé API | Préfixe | Description |
|---|
| Clé API personnelle | apk_user_ | Clés à portée utilisateur/organisation héritant des autorisations individuelles de l’utilisateur |
| Clé API de service | apk_ | Clés de service à l’échelle de l’organisation pour l’automatisation |
| Identifiant d’utilisateur de service | cog_ | Identifiants d’utilisateur de service Enterprise/organisation avec RBAC |
- Accédez à Settings > API Keys dans n’importe quelle sous-organisation
- Cliquez sur « Generate New API Key »
- Copiez et stockez la clé de manière sécurisée (elle ne sera affichée qu’une seule fois)
Versions d’API prises en charge :
- v1 : Oui - hérite des autorisations de l’utilisateur au niveau de l’organisation
- v2 : Oui - uniquement pour les utilisateurs avec le rôle d’administrateur Enterprise
- v3 : Non - utilisez plutôt des identifiants d’utilisateur de service
Cas d’utilisation recommandés :
- Scripts d’automatisation personnels
- Développement et tests
- Intégrations propres à un utilisateur
Considérations de sécurité :
- Les clés sont limitées aux autorisations de l’utilisateur
- La révocation de l’accès d’un utilisateur invalide automatiquement ses clés API
- Les clés doivent être renouvelées régulièrement
Clés d’API de service (portée organisationnelle)
- v1 : Oui - limitée à l’organisation
- v2 : Non - non prise en charge
- v3 : Non - utilisez plutôt des Service User Credentials
Cas d’utilisation recommandés :
- Automatisation au niveau de l’organisation
- Pipelines CI/CD limitées à des équipes spécifiques
- Outils partagés au sein d’une sous-organisation
Identifiants d’utilisateurs de service (v3 uniquement)
- Accédez à Enterprise Settings > Service Users
- Cliquez sur “Create Service User”
- Attribuez les rôles appropriés (Enterprise Admin, Org Admin, Org Member, etc.)
- Générez une API key pour l’utilisateur de service
Types d’utilisateurs de service :
- Enterprise Service Users : peuvent accéder à plusieurs organisations en fonction des rôles attribués
- Organization Service Users : limités à des organisations spécifiques avec des rôles au niveau de l’organisation
Versions d’API prises en charge :
- v1 : Non - non disponible
- v2 : Non - non disponible
- v3 : Oui - prise en charge complète du RBAC
Cas d’utilisation recommandés :
- Automatisation en production avec des autorisations granulaires
- Workflows multi-organisations
- Intégrations soumises à des impératifs de conformité nécessitant des journaux d’audit
- Intégrations de longue durée avec des périmètres d’autorisation spécifiques
Considérations de sécurité :
- Les utilisateurs de service apparaissent dans les journaux d’audit séparément des utilisateurs humains
- Les autorisations peuvent être contrôlées avec précision via le RBAC
- Les clés peuvent être remplacées sans affecter les comptes des utilisateurs humains
- Idéal pour appliquer le principe du moindre privilège
Méthodes d’authentification
Authentification par jeton Bearer
Authorization :
Authorization: Bearer your_api_key_here
curl -X POST "https://api.devin.ai/v1/sessions" \
-H "Authorization: Bearer YOUR_V1_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"prompt": "Créer un script Python simple"
}'
curl -X GET "https://api.devin.ai/v2/enterprise/organizations" \
-H "Authorization: Bearer YOUR_V2_ENTERPRISE_ADMIN_KEY"
curl -X GET "https://api.devin.ai/v3beta1/enterprise/organizations" \
-H "Authorization: Bearer YOUR_V3_SERVICE_USER_KEY"
Bonnes pratiques de sécurité
Ne partagez jamais d’API keys dans des espaces accessibles publiquement, comme les dépôts GitHub, le code côté client ou les journaux.
- Stockez les clés de manière sécurisée : utilisez des variables d’environnement ou des systèmes de gestion de secrets
- Renouvelez régulièrement les clés : générez de nouvelles clés et révoquez périodiquement les anciennes
- Utilisez des comptes de service pour l’automatisation : préférez les comptes de service v3 aux clés personnelles en production
- Appliquez le principe du moindre privilège : accordez uniquement les autorisations minimales nécessaires
- Surveillez l’utilisation : examinez les journaux d’audit pour détecter toute activité API inattendue
- Révoquez immédiatement les clés compromises : si une clé est exposée, révoquez-la et générez-en une nouvelle
Causes possibles :
- API key invalide ou expirée
- En-tête
Authorization manquant
- Format du jeton Bearer incorrect
Solution : Vérifiez que votre API key est valide et correctement formatée dans l’en-tête Authorization.
Causes possibles :
- L’API key ne dispose pas des autorisations requises
- Utilisation d’une version d’API inadaptée à votre type de clé (par ex. clé personnelle avec v3)
- Tentative d’accès à des ressources en dehors de votre périmètre d’autorisation
Solution :
- Pour v2 : assurez-vous de disposer du rôle d’administrateur Enterprise
- Pour v3 : utilisez des identifiants d’utilisateur de service avec les rôles appropriés
- Pour v1 : vérifiez que vous avez bien accès à l’organisation
Causes possibles :
- URL de l’endpoint de l’API incorrecte
- La ressource n’existe pas ou vous n’y avez pas accès
Solution : Vérifiez que l’URL de l’endpoint correspond bien à la version de l’API que vous utilisez et que la ressource existe bien.
