Usage and billing
Every call you make is a row you can read, and the rows add up to the invoice. If they ever do not, that is a bug and we will refund the difference.
Two numbers
A call costs the credits published on the pricing page and on every endpoint’s own page. A call we fail costs 0, refunded automatically. That is the whole model — there is no third number, and nothing depends on compute time, response size, whether we had the answer cached, or anything else you cannot see before you call.
The ledger
GET /v1/usage returns one row per call, newest first — the same rows the dashboard shows under Requests. A call we failed is still a row: it costs 0, says refunded: true, and gives the credits it handed back in credits_refunded. A cache hit costs what a fetch costs, and says cached: true.
{
"data": [
{ "ts": "2026-09-20T09:14:41Z", "endpoint": "linkedin/profile",
"credits": 0, "refunded": true, "credits_refunded": 10,
"cached": false, "status": 502, "duration_ms": 25004 },
{ "ts": "2026-09-20T09:12:05Z", "endpoint": "tiktok/profile",
"credits": 3, "refunded": false, "credits_refunded": 0,
"cached": true, "status": 200, "duration_ms": 8 },
{ "ts": "2026-09-20T09:12:03Z", "endpoint": "tiktok/profile",
"credits": 3, "refunded": false, "credits_refunded": 0,
"cached": false, "status": 200, "duration_ms": 412 }
]
}GET /v1/account gives the same thing rolled up: credits remaining, credits granted this period, your concurrency limit and how much of it is in use, and per-endpoint totals.
Running out
When the balance reaches zero, calls are refused with insufficient_credits and nothing is charged. There is no overage and no automatic top-up: you buy credits when you choose to, and you are never billed for something you did not choose. To hear about it first, set a low-balance email on the dashboard’s billing page — it goes once each time the balance crosses your line.
Expiry
Credits do not expire. There is no subscription and no billing cycle for them to expire at the end of — credits you buy stay bought.