Stellar rate limits and tiers
Stellar traffic on Triport is metered per second in two buckets,
stellar_read_rpcandstellar_read_rpc_heavy, shared by Soroban JSON-RPC, Horizon REST and Horizon SSE. This page lists the per-tier budgets, which calls are heavy, and how a 429 tells you which budget you hit.
Endpoint and plans: Stellar RPC endpoint.
Budgets per tier
Values are sustained RPS / short burst capacity. The included 2× burst buffer absorbs brief traffic spikes at no extra cost and refills at the sustained rate. There is no quota on the number of bursts. Size ongoing traffic to sustained RPS; unlimited categories have no numeric burst ceiling. See Burst capacity.
| Category | Free | Basic | Pro | Business | Enterprise |
|---|---|---|---|---|---|
stellar_read_rpc | 15 / 30 | 20 / 40 | 100 / 200 | 250 / 500 | unlimited |
stellar_read_rpc_heavy | 15 / 30 | 20 / 40 | 100 / 200 | 250 / 500 | unlimited |
Both rows are unmeasured product-policy defaults, inherited from the Polygon budgets of the same tier until a dedicated Stellar capacity test. They are throttles Triport applies to your key, not a statement about upstream capacity. An Enterprise "unlimited" entry means no configured tier cap, not unlimited physical capacity. The Free column is the 7-day trial: EU region only, one API key.
There is no daily or monthly request quota: the only limit to plan around is the per-second budget of each category.
Which calls are heavy
The two buckets have the same numbers today, but they are counted separately, so heavy history scans do not eat the budget of your ordinary reads.
| Surface | stellar_read_rpc_heavy | stellar_read_rpc |
|---|---|---|
| Soroban JSON-RPC | getEvents, getTransactions | getFeeStats, getHealth, getLatestLedger, getLedgerEntries, getLedgers, getNetwork, getVersionInfo, simulateTransaction |
| Horizon REST | GET /payments, GET /operations, GET /accounts/{account}/payments | GET /, GET /accounts/{account}, GET /accounts/{account}/transactions, GET /assets, GET /fee_stats, GET /ledgers, GET /ledgers/{ledger}, GET /transactions |
| Horizon SSE | /ledgers and /transactions streams | — |
How requests are counted
- A JSON-RPC batch is charged one request per element, not one per HTTP
call. A batch of 20
getLedgerEntriescalls spends 20 of thestellar_read_rpcbudget. - Horizon pages are capped at
limit=200records. A largerlimitis rejected with HTTP400(limit must not exceed 200), so page with cursors instead of asking for more per request. - History has a measured window: Soroban keeps about 120,960 ledgers, Horizon
6,307,191 ledgers. A request below the window returns
beyond_retention(HTTP410on Horizon,-32602on Soroban); see Stellar errors.
When you hit a limit
Going over sustained + burst returns HTTP 429 with "error": "rate_limited".
The body names the budget you hit — category (for example
stellar_read_rpc_heavy), current_tier, limit_rps and burst_capacity —
and the Retry-After header gives the wait in seconds, never less than 1. Wait
that long, then retry with exponential backoff and jitter. A method above your
tier is a different answer: 403 tier_insufficient.
The shared model, response headers and code samples are in Rate Limits and Tiers and the shared error reference.