Skip to main content
Les API v2 sont en alpha et peuvent être modifiées à tout moment.

​
Vue d’ensemble

API d’analyse v2 est la nouvelle génération de l’API d’analyse de Devin Desktop. Elle expose les données de consommation (crédits et ACU), les utilisateurs actifs et la production des agents (lignes de code acceptées) via des endpoints REST clairs, avec filtrage par paramètres de requête, regroupement flexible et pagination par curseur.
Les endpoints v2 sont actuellement disponibles sous le préfixe /api/v2alpha tant que l’API n’est pas finalisée. L’URL de base est https://server.codeium.com.

​
Nouveautés de la v2

Le changement le plus important par rapport à v1 est l’authentification.

​
Authentification

v2 utilise l’authentification par jeton Bearer. Transmettez votre identifiant dans l’en-tête Authorization plutôt que dans le corps de la requête :
Deux types d’identifiants sont acceptés : une API key d’utilisateur de service Devin (recommandée — la même clé cog_ que vous utilisez pour la Devin API) ou une clé de service Windsurf.

​
API keys d’utilisateur de service Devin

Si vous gérez déjà des utilisateurs de service Devin, vous n’avez pas besoin d’identifiants Windsurf distincts :
  1. Provisionnez un utilisateur de service dans Settings > API Devin (onglet utilisateurs de service) pour une organisation, ou Enterprise settings > API Devin (onglet utilisateurs de service) pour l’enterprise
  2. Attribuez-lui un rôle personnalisé incluant l’autorisation Utiliser l’API d’analyse locale (le rôle d’administrateur intégré l’inclut déjà)
  3. Copiez l’API key affichée après le provisioning — elle commence par cog_
  4. Utilisez cette clé comme jeton Bearer
Les résultats couvrent l’ensemble du compte Devin auquel appartient l’utilisateur de service, et metadata.team_id correspond à l’identifiant de la Team Devin du compte (devin-team$<account_id>).
Le filtre group_id est propre aux Teams Windsurf et n’est pas pris en charge avec les identifiants Devin ; les requêtes combinant les deux renvoient 400 Bad Request.

​
Clés de service Windsurf

  1. Accédez à votre page Team Settings
  2. Accédez à la section “Service Keys”
  3. Créez une nouvelle clé de service avec l’autorisation Analytics Read
  4. Utilisez la clé comme jeton Bearer dans l’en-tête Authorization
Les clés de service associées à un groupe sont prises en charge — lorsqu’une clé est associée à un groupe, les résultats sont automatiquement limités à ce groupe.
Conservez ces identifiants en lieu sûr et ne les exposez jamais dans du code côté client ou des dépôts publics.

​
Endpoints disponibles

​
Stratégie de facturation

Les réponses de consommation s’adaptent à la stratégie de facturation de votre Team, indiquée dans metadata.billing_strategy (les réponses relatives à la production et aux utilisateurs actifs ne sont pas concernées) :
  • CREDITS — les lignes incluent prompt_credits et flex_credits
  • ACU — les lignes incluent billed_acus
Les champs message_count (événements de facturation) et user_message_count (messages envoyés par l’utilisateur, null pour l’utilisation antérieure au 2026-04-11) sont toujours renvoyés, quelle que soit la stratégie.

​
Pagination

Les réponses de liste sont paginées. Lorsque d’autres données sont disponibles, la réponse inclut un pagination.next_page_cursor ; transmettez-le dans le paramètre de requête page_cursor pour récupérer la page suivante. Les curseurs expirent après 24 heures.

​
Limites de taux

Ces endpoints ne sont pas destinés au suivi de l’utilisation en temps réel. Les données sont agrégées par heure et la limite de taux est faible (10 requêtes par heure par Team). Utilisez-les pour des rapports périodiques et des exports en masse, pas pour des tableaux de bord en direct ni pour un suivi requête par requête.
Les endpoints v2 sont limités à 10 requêtes par heure par Team. Si vous dépassez la limite, la réponse renvoie 429 Too Many Requests avec un en-tête Retry-After. La pagination d’une requête précédente (en suivant un next_page_cursor) n’est pas comptabilisée dans la limite de taux — seule la requête initiale de chaque rapport l’est. Cette faible limite reflète le fait que ces endpoints sont destinés à des rapports périodiques, et non à la surveillance en temps réel.