Le API v2 sono in alpha e sono soggette a modifiche in qualsiasi momento.
L’API di analisi v2 è la nuova generazione dell’API di analisi di Devin Desktop. Espone i dati di consumo
(crediti e ACU) tramite endpoint REST chiari, con filtri tramite parametri di query, raggruppamento
flessibile, paginazione basata su cursore e cache delle risposte.
Gli endpoint v2 sono attualmente disponibili con il prefisso /api/v2alpha mentre l’API è in fase di
definizione finale. L’URL di base è https://server.codeium.com.
La differenza principale rispetto a v1 è l’autenticazione.
| API di analisi v1 | API di analisi v2 |
|---|
| Trasporto | POST con un corpo della richiesta in formato JSON | GET con parametri di query |
| Autenticazione | campo service_key nel corpo della richiesta | header Authorization: Bearer <service_key> |
| Autorizzazione | Varia in base all’endpoint | Analytics Read |
| Paginazione | Nessuna | Basata su cursore (next_page_cursor / page_cursor) |
| Cache | Nessuna | ETag + If-None-Match (304 Not Modified) |
v2 utilizza l’autenticazione con token Bearer. Passa la tua chiave di servizio nell’header Authorization anziché
nel corpo della richiesta:
Authorization: Bearer <your_service_key>
La chiave di servizio deve disporre dell’autorizzazione Analytics Read.
Creazione di una chiave di servizio
- Vai alla pagina Team Settings del tuo team
- Vai alla sezione “Service Keys”
- Crea una nuova chiave di servizio con l’autorizzazione Analytics Read
- Usa la chiave come token Bearer nell’header
Authorization
Tieni al sicuro le tue chiavi di servizio e non esporle mai nel codice lato client o in repository pubblici.
Sono supportate chiavi di servizio con ambito di gruppo: quando una chiave è limitata a un gruppo, i risultati vengono automaticamente
limitati a quel gruppo.
| Endpoint | Descrizione |
|---|
Recupera il consumo (GET /api/v2alpha/analytics/consumption) | Recupera il consumo di crediti o ACU con filtri, raggruppamento, granularità e paginazione |
Recupera gli utenti attivi (GET /api/v2alpha/analytics/active-users) | Conta gli utenti attivi univoci, facoltativamente per giorno/mese o per singolo utente |
Strategia di fatturazione
Le risposte si adattano alla strategia di fatturazione del team, indicata in metadata.billing_strategy:
CREDITS — le righe includono prompt_credits e flex_credits
ACU — le righe includono billed_acus
Il campo message_count viene sempre restituito, indipendentemente dalla strategia.
Le risposte che restituiscono elenchi sono paginate. Quando sono disponibili altri dati, la risposta include un
pagination.next_page_cursor; passalo di nuovo come parametro di query page_cursor per recuperare la pagina
successiva. I cursori scadono dopo 24 ore.
Le risposte includono un header ETag. Nelle richieste successive, invialo di nuovo nell’header If-None-Match
per ricevere un 304 Not Modified se i dati non sono cambiati.
Questi endpoint non sono destinati al monitoraggio dell’utilizzo in tempo reale. I dati vengono
aggregati su base oraria e il limite di frequenza è basso (10 richieste all’ora per team). Usali per report periodici ed esportazioni in blocco,
non per dashboard in tempo reale o per il tracciamento delle singole richieste.
Gli endpoint v2 sono soggetti a un limite di frequenza di 10 richieste all’ora per team. Se il limite viene superato, viene restituito
429 Too Many Requests con un header Retry-After.
La paginazione di una query precedente (seguendo un next_page_cursor) non viene conteggiata ai fini del
limite di frequenza — viene conteggiata solo la query iniziale per ciascun report. Il limite ridotto riflette il fatto che questi endpoint sono
pensati per report periodici, non per il monitoraggio in tempo reale.