GET /v1/usage returns your plan, a usage rollup grouped by (surface, region) covering the last 30 days (UTC-day aligned), and your remaining credit balance. The daily series spans a wider 90-day trend window. It’s a read-only snapshot — nothing here mutates state.

Request

This endpoint takes no parameters. It requires a valid Authorization: Bearer <API_KEY> header like every authenticated route.

Response

plan
string
Your current plan identifier.
usage
object
Your usage ledger, rolled up by the never-blended (surface, region) key.
balance
object
Your remaining credit balance.

Per-child accounting

Usage is counted per child capture, not per request. A single POST /v1/search fans out into one child per surface × region, and each child is recorded independently against its exact (surface, region) group. A search across N surfaces and M regions produces N × M child captures. For example, surfaces: ["chatgpt", "claude", "perplexity"] with regions: [{ "country": "US" }, { "country": "GB" }] is 3 × 2 = 6 captures, adding 6 to totals.callCount across six groups.

Credits vs. calls

callCount counts captures; creditsCharged tracks what they cost. They’re related but not identical: a capture only draws down credits when it succeeds. An empty capture (surfacePresent: false) or a failed one is not billed. Per-capture credit costs vary by surface. See Credits & pricing for the full table.
Internal (first-party) keys can scope this read to a single tenant with the ?owner= query parameter or the X-AISearch-On-Behalf-Of header; the enforced owner is echoed back in the body (owner) and the X-AISearch-Owner header. Customer (sk_*) keys are always scoped to their own account — an override is ignored.

Credits & pricing

What each capture costs and how billing works.

Job lifecycle

How parent and child jobs move through terminal states.