Authentification

Identifiants d’utilisateur de service (recommandé)

Les utilisateurs de service sont des comptes de bot dédiés à l’accès à l’API, avec des autorisations définies par rôle. C’est la méthode d’authentification recommandée pour toutes les nouvelles intégrations.

Fonctionnement

Créez un utilisateur de service dans Settings > Service users
Attribuez un rôle qui contrôle les endpoints auxquels l’utilisateur de service peut accéder
Générez une API key (elle commence par cog_)
Incluez la clé dans l’en-tête Authorization de chaque requête

curl -X POST "https://api.devin.ai/v3/organizations/$DEVIN_ORG_ID/sessions" \
  -H "Authorization: Bearer $DEVIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Create a simple Python script"}'

Portées des utilisateurs de service

Portée	Créé dans	Accès API	Cas d’utilisation
Organization	Settings > Service users	`/v3/organizations/*`	Gestion des sessions, Knowledge, playbooks, secrets
Enterprise	Enterprise settings > Service users	`/v3/enterprise/` + `/v3/organizations/`	Gestion inter-organisations, analyses, journaux d’audit, facturation

Trouvez l’ID de votre organisation sur la page Settings → Service Users.

Attribution des sessions avec `create_as_user_id`

Les utilisateurs de service sont des identités distinctes des utilisateurs humains. Par défaut, les sessions créées par un utilisateur de service sont attribuées à cet utilisateur de service lui-même. Pour créer des sessions au nom d’un utilisateur spécifique, passez le paramètre create_as_user_id lors de la création d’une session. La session apparaîtra dans la liste des sessions de cet utilisateur et sera prise en compte dans son utilisation. Cela nécessite l’autorisation ImpersonateOrgSessions sur le rôle de l’utilisateur de service.

Vous migrez depuis des API keys personnelles ? Les API keys personnelles (v1/v2) créaient automatiquement les sessions sous votre identité d’utilisateur. Avec les utilisateurs de service, utilisez create_as_user_id pour obtenir le même comportement — avec, en plus, le RBAC, des journaux d’audit et une gestion centralisée des clés. Consultez la présentation de l’API pour un exemple.

Principales propriétés

Les clés commencent par cog_ et ne sont affichées qu’une seule fois lors de leur création
Les utilisateurs de service apparaissent séparément des utilisateurs humains dans les journaux d’audit
Les autorisations sont contrôlées via le RBAC — n’attribuez que ce dont l’intégration a besoin
Les utilisateurs de service Enterprise héritent des autorisations au niveau de l’org, dans toutes les organisations

Pour des instructions détaillées de configuration, consultez le guide de démarrage rapide Teams ou le guide de démarrage rapide Enterprise.

Anciennes API keys

Les anciennes API keys sont en voie de dépréciation au profit des utilisateurs de service. Nous recommandons de migrer les intégrations existantes vers des utilisateurs de service. Voir le guide de migration.

Les anciennes API keys sont utilisées avec les API v1 et v2. Elles continuent de fonctionner pendant la période de dépréciation, mais ne prennent pas en charge les nouvelles fonctionnalités comme le RBAC, l’attribution de session ou la pagination basée sur un curseur.

Type de clé	Préfixe	Utilisé avec	Description
Clé d’API personnelle	`apk_user_`	v1, v2	Liée à un compte utilisateur, hérite des autorisations de l’utilisateur
Clé d’API de service	`apk_`	v1	Portée organisationnelle, pour l’automatisation

Où les générer : Settings > API Keys