Skip to main content

​
Every request costs 10 credits

Every authenticated request consumes exactly 10 credits. The cost does not change with the size of the response, the width of the startDate/endDate window, the timeframe, or which endpoint you call. A one-day series and a ten-year series cost the same. This makes usage predictable: divide your credit balance by 10 and you have your request count.

​
Reading your balance

Every response carries the remaining balance in a header:
There is no need to poll a separate endpoint — read the header on the responses you are already making.

​
Failed requests are refunded

If a request comes back with anything other than a 2xx status, the credit is returned to your balance automatically. Errors on our side, validation failures and not-found responses do not cost you credits.

​
When the balance runs out

Once consumption reaches your allocation, further requests are rejected with HTTP 402:
The request is not served and no credit is consumed. Existing keys keep working the moment more credits are added or the cycle rolls over.

​
Allocation and renewal

Your balance is the sum of two parts:
  • Plan allocation — granted by your subscription, in the table above.
  • Top-ups — extra credits added to the current period.
On a paid plan, consumption is counted per billing period, anchored on your billing cycle day: when a new period starts, consumption resets to zero and the allocation applies again. The free grant is not a monthly allowance — it is a single pool that does not renew. Top-ups add to whichever of the two applies to you.

​
If credit tracking is unavailable

Credit accounting is durable and enforced before the request runs. In the rare case the accounting layer cannot be reached, the API answers HTTP 503 with DurableCreditTrackingUnavailable rather than serving a request it cannot account for.
Credits and rate limits are separate controls. Credits cap how much you consume over a billing period; rate limits cap how fast. See Rate Limits.