Rate limits & tiers
Two endpoint dimensions are metered: stream egress (GB delivered) and RPC plus /info request rate (req/s). Manual historical work is scoped and quoted separately. Endpoint limits are per key and set by your tier. Full pricing and the usage calculator live on /pricing.
Tier gates
| Feature | Build | Scale |
|---|---|---|
| Usage | ||
| Base price | $50/mo | $200/mo |
| First month (discounted) | $25 | $100 |
| Combined requests per second | 250 | 1,000 |
| API keys | 5 | 25 |
| History depth | 90 days | Full history |
| Billing | Monthly or annual | Monthly or annual |
Base price
First month (discounted)
Combined requests per second
API keys
History depth
Billing
Stream availability per tier (which streams, filter breadth, replay) are on the full pricing matrix.
What happens at the limit
The honest version: paid tiers are not hard-capped. Streams keep flowing and RPC keeps answering past your included quota; the overage bills at the published per-GB and per-million-request rates. No mid-session cutoff. Hard 429s only appear when you push past your plan's req/s rate; back off and retry.
Staying under your limits
- Filter server-side.
coinsandwalletsfilters mean you only receive what you subscribe to, and only pay egress for that. - Take the narrowest stream that answers your question: choosing a stream maps needs to surfaces. A BTC ticker over the book-diffs firehose is the classic mistake.
- Watch consumption in the console. Usage is metered per key, so one key per consumer tells you exactly where the gigabytes go.
- If your estimate keeps crossing tiers, run the usage calculator; past a point, a dedicated node with private throughput is the better shape (Enterprise).