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
Authorization: Bearer <API_KEY> header like every authenticated route.
Response
Your current plan identifier.
Your usage ledger, rolled up by the never-blended
(surface, region) key.Your remaining credit balance.
Per-child accounting
Usage is counted per child capture, not per request. A singlePOST /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.