Skip to main content

​
RPC Authentication

All OrbitFlare RPC requests are authenticated by appending your license key as a query parameter to the endpoint URL. 
curl -X POST "https://mainnet.rpc.orbitflare.com?api_key=YOUR_LICENSE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getBlockHeight"
  }'
Your RPC license key is provided with your OrbitFlare service subscription. You can find it in the Licenses section of your OrbitFlare Dashboard.

​
Customer API Authentication

The Customer API uses a different authentication method. Pass your API key via the X-ORBIT-KEY HTTP header: 
curl -X GET https://api.orbitflare.com/customer/v2/licenses \
  -H "X-ORBIT-KEY: YOUR_API_KEY"
Customer API v2 also supports Bearer token authentication obtained through the device flow or wallet signature auth. See the Customer API docs for details.

​
RPC Endpoints

OrbitFlare provides geo-distributed RPC endpoints so you can route requests to the region closest to your users or infrastructure. The URL format is: 
https://{region}.rpc.orbitflare.com?api_key=YOUR_API_KEY
Replace {region} with one of the region codes below.

​
Available Regions

CityRegion CodeEndpoint
Ashburnashhttps://ash.rpc.orbitflare.com?api_key=YOUR_API_KEY
New Yorknyhttps://ny.rpc.orbitflare.com?api_key=YOUR_API_KEY
Los Angeleslahttps://la.rpc.orbitflare.com?api_key=YOUR_API_KEY
Salt Lake Cityslchttps://slc.rpc.orbitflare.com?api_key=YOUR_API_KEY

​
Mainnet Endpoint (Auto-Routed)

If you do not need to pin requests to a specific region, use the mainnet endpoint. OrbitFlare will direct each request to the nearest available region automatically. 
https://mainnet.rpc.orbitflare.com?api_key=YOUR_API_KEY
The mainnet endpoint is recommended for most use cases. It provides the lowest latency without requiring you to manage region selection.

​
WebSocket Endpoints

WebSocket connections use the same region codes with the wss:// scheme: 
wss://{region}.rpc.orbitflare.com?api_key=YOUR_API_KEY
For auto-routed WebSocket connections: 
wss://mainnet.rpc.orbitflare.com?api_key=YOUR_API_KEY
Authentication is handled through the same api_key query parameter.

​
Devnet

OrbitFlare provides a dedicated Devnet endpoint for development and testing: 
https://devnet.rpc.orbitflare.com?api_key=YOUR_API_KEY
The Devnet endpoint connects to the Solana Devnet. Do not use it for production workloads. Devnet tokens have no monetary value.

​
Rate Limits by Plan

Each plan defines a maximum number of requests per second (RPS) and transactions per second (TPS).
PlanRequests per Second (RPS)Transactions per Second (TPS)
Free101
Developer5010
Growth20075
Scale400150
Pro600200
DedicatedUnlimitedUnlimited
Requests that exceed your plan’s RPS or TPS limit will receive an HTTP 429 Too Many Requests response. Implement exponential backoff in your client to handle these gracefully.
No. OrbitFlare does not impose monthly credit limits or request caps. You can send unlimited total requests within your plan’s per-second rate limit.
OrbitFlare plans have no credit limits — you can make unlimited requests as long as you stay within your plan’s per-second rate tier. There are no surprise overage charges.

​
Data Streaming Connection Limits

Connection limits apply independently of your RPC rate limit tier and are enforced per IP address across all streaming interfaces.

​
gRPC (Jetstream / Yellowstone)

LimitValue
Concurrent connections per IP50
Subscriptions per connectionUnlimited
Idle connection timeout10 minutes (use ping to keep alive)
The 50-connection cap is shared across all gRPC endpoints (Jetstream and Yellowstone) originating from the same IP address. This applies regardless of which region you connect to.
Dedicated gRPC nodes are not subject to the shared connection limit. If you need more than 50 concurrent gRPC connections, contact the team about a dedicated gRPC node.
Keeping connections alive Cloud load balancers and proxies (including Cloudflare) may close idle gRPC streams after ~10 minutes. Send a ping every 30 seconds to prevent disconnection: 
const pingRequest: SubscribeRequest = {
  ping: { id: 1 },
  accounts: {},
  accountsDataSlice: [],
  transactions: {},
  transactionsStatus: {},
  blocks: {},
  blocksMeta: {},
  slots: {},
  entry: {},
};

setInterval(() => {
  stream.write(pingRequest, (err) => {
    if (err) console.error("Ping failed:", err);
  });
}, 30_000);
What happens when the limit is exceeded When your IP has 50 active gRPC connections and you attempt to open a new one, the server returns a gRPC RESOURCE_EXHAUSTED status: 
StatusCode: RESOURCE_EXHAUSTED
Message: connection limit exceeded
Close unused streams before opening new ones. Implement exponential backoff when reconnecting after a RESOURCE_EXHAUSTED error.

​
WebSocket

LimitValue
Concurrent connections per IP50
Subscriptions per connectionVaries by plan
Idle connection timeout60 seconds without a message
WebSocket connections use the same 50 concurrent connections per IP limit. Connections idle for more than 60 seconds without any message exchange will be closed by the server. What happens when the limit is exceeded New WebSocket connections attempted beyond the limit are rejected with a 1008 Policy Violation close code: 
WebSocket closed: 1008 Policy Violation - connection limit exceeded
The 50-connection limit applies to all shared plans. If your workload requires more concurrent streaming connections, a Dedicated gRPC Node or Dedicated RPC Node removes the shared limit entirely. Contact the team on Discord to discuss options.
The limit is enforced globally per IP address, across all regions. A single IP with 30 connections to Frankfurt and 20 connections to New York has reached the 50-connection cap.
Use exponential backoff when reconnecting after a connection error. Start with a 1-second delay, doubling on each failed attempt up to a maximum of 30 seconds. Always close streams cleanly before reconnecting to avoid exhausting your connection quota.