Skip to main content
All endpoints live under the base URL and require a Bearer API key (the same key used for the inference API). The org is derived from the key.
Routes fall into two families: Billing & cost (spend, balance, and token counters) and Operational activity & latency (request counts, tasks, and latency distributions).

Common parameters

Most routes accept a rolling-window range and, for the operational routes, an environment filter.
range never returns a 400 for an unrecognized value. It silently falls back to the endpoint’s default window. Invalid environment, date, start, end, bucket_size, status, kind, or after values do return 400, as does an unsupported sla on /tasks and /latency/timeseries. On GET /v2/usage, an unrecognized sla or model is not rejected. It is applied as a filter that matches nothing.
Monetary fields (balance, period_spend, burn_rate, avg_cost_per_day, product_spend, sailbox_spend, and breakdown total) are fractional USD cents expressed as floats. For example 73795.09 is roughly $737.95. Token fields on the public endpoints are raw inference token counts.

Product accounting

Billing responses follow these guarantees:
  • period_spend and each breakdown bucket’s total include all positive Inference and Sailbox charges.
  • product_spend always contains exactly two product families, inference and sailboxes. It never emits an other family, and the two values add up to the corresponding combined total.
  • sailbox_spend reports the currently itemized Sailbox charges. Sailbox products without a line item still count toward product_spend.sailboxes, so the line-item fields may sum to less than it.
  • Token, model, completion-window, request, and latency metrics are inference-only. Sailbox quantities and identifiers are not represented as tokens, models, or completion windows.
  • Only base input, output, and cached-input token products add token counts. Surcharges add inference spend without duplicating token quantities. Cached input is included in input, so total = input + output and cached tokens must not be added to total again.
  • Model and completion-window breakdowns include only explicitly attributed inference spend. Missing attribution stays unassigned instead of creating an other model or completion window.
To calculate product percentages, divide each product amount by the combined total. When the combined total is zero, both percentages are zero.

Billing & cost

GET /v2/usage/summary

Combined Inference and Sailbox spend, credit balance, burn rate, days remaining, inference token totals, inference SLA spend mix, and a prior-period comparison.
Plan tier is not exposed via the API; it is shown only on the dashboard.

GET /v2/usage/breakdown

Combined spend and inference token breakdowns per time bucket, plus inference model cost rankings. Use range=day with date=YYYY-MM-DD to drill into a single day at hourly granularity.
Inference spend without a completion-window attribution is the remainder below. It is plain inference spend, not an other product or completion window.

GET /v2/usage/api-keys

Per-API-key usage, broken down by (api_key_id, model, sla), with a windowed time series. display_name and display_prefix are populated for keys that still exist; deleted keys return null for both (only the stable api_key_id remains).
This endpoint reports inference usage only. Sailbox charges accrue over a Sailbox’s lifetime and do not map reliably to a single API key, so Sailbox usage is excluded from the per-key rows. Use /v2/usage/summary or /v2/usage/breakdown for product-aware spend.

GET /v2/usage/tokens

Inference token counters (input/output/cached) over the range, as raw counts. Only base token products contribute quantities. Sailbox usage and inference surcharges do not add tokens. Cached input is already included in input.

GET /v2/usage/tokens/timeseries

Raw inference token counts per time bucket, broken down by input/output/cached. The same base-product and cached-input rules as /tokens apply.

Operational activity & latency

These routes report request counts, task activity, and latency. They all accept the environment filter.

GET /v2/usage/activity

Consolidated completed-request counts and average latency over rolling windows.

GET /v2/usage/activity/timeseries

Per-model completed-request counts over time.

GET /v2/usage/recent

The most recent requests, including active and finished requests when available.
sla is null when the request has no resolved completion window.

GET /v2/usage/tasks

Paginated task activity with per-task token breakdowns, spanning both active and finished requests. Only 1h and 24h are valid for range; any other value resolves to 24h (reported back as effective_range).

GET /v2/usage/latency/turn

Turn latency distribution for a single request-to-response time, with p50/p95/p99, aggregate and per-SLA.

GET /v2/usage/latency/trajectory

Trajectory latency distribution for a multi-turn conversation, with the same shape as /latency/turn. Trajectory responses additionally carry avg_turns_per_trajectory, and may set approx: true when percentiles are sampled.

GET /v2/usage/latency/timeseries

Latency percentiles over time for turns or trajectories.
model and sla filters are only supported for kind=turn. Passing either with kind=trajectory returns a 400.
Series points include approx and avg_turns_per_trajectory only when relevant (both are omitted otherwise).

GET /v2/usage

Completed-request latency and counts in fixed time buckets, with one row per environment per bucket. Unlike the rolling-window routes above, this endpoint takes an explicit start/end/bucket_size window, making it suited to charting a specific time range at a fixed resolution.
A window that would produce more than 10,000 buckets for the chosen bucket_size returns a 400. Widen bucket_size or shorten the window.
Empty buckets are included (with zeroed counts) so a series has no gaps.

Errors

Errors use the same envelope as the inference API. For usage-API errors, code is set to the same string as type, and param is always null:
Authentication and rate-limit failures are produced by the shared API middleware and may carry a distinct code (for example invalid_api_key) or null (a missing Authorization header). Endpoints return an empty/zeroed payload with HTTP 200 (not an error) when the org has no billing account or no usage in the requested window.