Request lookup and activity
Every response has a request id; here is what it unlocks.
One request
GET /v1/generation/{id} returns the record for one request, merging two sources: the ledger (authoritative cost, source.cost = "ledger") and analytics (timings, upstream attempts, source.timing = "analytics"). It needs the read:usage scope.
sleep "${AIML_ANALYTICS_WAIT:-3}"
curl -sS "$CPAPI/v1/generation/$RID" -H "Authorization: Bearer $AIML_API_KEY"Analytics is ingested asynchronously. Right after a call the timing fields may be missing while cost is already final; the cookbook waits a few seconds for that reason.
The activity feed
GET /v1/requests pages the org's requests newest first with the filters the console uses (since, until, project_id, key_id, model, provider, status, errors_only, fallbacks_only, min_cost_micro, max_cost_micro, q for a request-id prefix). The response header x-aiml-analytics-lag-s reports ingest lag; the console shows a banner above 60 s.
GET /v1/requests/tail is a server-sent events stream of new rows (event: request), polled every interval_ms; pass after=<request_id> to resume.
Retention
Request metadata (tokens, cost, timings, status) is kept for analytics. Prompt and completion content is not stored unless the key's data policy opts into logging (logged: true on the row).