Passer au contenu principal
Les API v2 sont en alpha et peuvent être modifiées à tout moment.

​
Vue d’ensemble

Analytics API v2 est la nouvelle génération de l’Analytics API de Devin Desktop. Elle expose les données de consommation (crédits et ACU) via des endpoints REST clairs, avec filtrage par paramètres de requête, regroupement flexible, pagination par curseur et mise en cache des réponses.
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.
Analytics API v1Analytics API v2
TransportPOST avec un corps de requête JSONGET avec des paramètres de requête
Authentificationchamp service_key dans le corps de la requêteen-tête Authorization: Bearer <service_key>
AutorisationVarie selon l’endpointAnalytics Read
PaginationAucunepagination par curseur (next_page_cursor / page_cursor)
Mise en cacheAucuneETag + If-None-Match (304 Not Modified)

​
Authentification

v2 utilise l’authentification par jeton Bearer. Transmettez votre clé de service dans l’en-tête Authorization plutôt que dans le corps de la requête : 
Authorization: Bearer <your_service_key>
La clé de service doit disposer de l’autorisation Analytics Read.

​
Création d’une clé de service

  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
Conservez vos clés de service en lieu sûr et ne les exposez jamais dans du code côté client ou des dépôts publics.
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.

​
Endpoints disponibles

EndpointDescription
Récupérer la consommation (GET /api/v2alpha/analytics/consumption)Consulter la consommation de crédits ou d’ACU avec filtrage, regroupement, granularité et pagination
Récupérer les utilisateurs actifs (GET /api/v2alpha/analytics/active-users)Compter le nombre d’utilisateurs actifs distincts, éventuellement par jour/mois ou par utilisateur

​
Stratégie de facturation

Les réponses s’adaptent à la stratégie de facturation de votre Team, indiquée dans metadata.billing_strategy :
  • CREDITS — les lignes incluent prompt_credits et flex_credits
  • ACU — les lignes incluent billed_acus
Le champ message_count est toujours renvoyé, quelle que soit la stratégie. 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.

​
Mise en cache

Les réponses comprennent un en-tête ETag. Renvoyez-le dans l’en-tête If-None-Match lors des requêtes suivantes pour recevoir une réponse 304 Not Modified si les données sont inchangées.

​
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.