Billing

One pricing model, in cents, measured per call. You top up a prepaid balance; each call debits cost_cents from it. No invoices, no overage math, no guessing.

The unit: cents

Every priced response carries a usage.cost_cents field — that's what came out of your credit balance. Cents are whole numbers (no fractional billing). A call that costs 75¢ debits exactly 75 cents.

/v1/ask price ladder

ShapePer call
Cache hit (any tier)
Single provider, no web search
Single provider, with web search15¢
Multi-provider (2–4), no web search25¢
Multi-provider (2–4), with web search75¢

Every API call deducts cost_cents from your balance. See the pricing page for the full per-call price ladder.

Other endpoints

  • GET /v1/mentions/search — flat 10¢ per call.
  • POST /v1/mentions/crawl — flat $2.00 (200¢) per call.
  • POST /v1/extract_brands, GET /v1/usage, GET /v1/ask/:id, and all /v1/keys / /v1/webhooks / /v1/monitors management calls — free.

Failed calls

If zero providers succeed on a /v1/ask call, you are not charged — cost_cents is 0. Partial success (e.g. 3 of 4 providers returned) is charged at the multi-provider tier; you are not refunded for individual failures, because we still did the fan-out.

Insufficient balance

If your balance is below the worst-case fresh cost of the call you're making, we return 402 insufficient_credits before dispatching the fan-out. The response body includes balance_cents and required_cents so your client can surface the exact amount to top up.

Reading your usage

GET /v1/usage returns request counts, cache-hit counts, error counts, and per-provider breakdowns over any window you ask for. Use it to drive in-app meters or to reconcile against Stripe invoices.

Topping up

Top up from the dashboard billing page. Balance is held in the same cents unit the API returns, so what you see in the response and what you see on the invoice are the same numbers.