> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbitflare.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Authentication & Limits
> Authenticate Solana JSON-RPC with your license key on the query string, understand per-plan rate and connection limits, HTTP semantics, and errors for production workloads on OrbitFlare.
## RPC Authentication
All OrbitFlare RPC requests are authenticated by appending your license key as a query parameter to the endpoint URL.
```bash theme={null}
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](https://orbitflare.com/dashboard).
## Customer API Authentication
The [Customer API](/api-documentation/welcome) uses a different authentication method. Pass your API key via the `X-ORBIT-KEY` HTTP header:
```bash theme={null}
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](/api-documentation/welcome) 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
| City | Region Code | Endpoint |
| -------------- | ----------- | ----------------------------------------------------- |
| Ashburn | `ash` | `https://ash.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| New York | `ny` | `https://ny.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| Los Angeles | `la` | `https://la.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| Salt Lake City | `slc` | `https://slc.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| City | Region Code | Endpoint |
| ------------------- | ----------- | ------------------------------------------------------ |
| Amsterdam | `ams` | `https://ams.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| Frankfurt | `fra` | `https://fra.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| London | `lon` | `https://lon.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| Dublin | `dub` | `https://dub.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| Siauliai, Lithuania | `siau` | `https://siau.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| City | Region Code | Endpoint |
| --------- | ----------- | ----------------------------------------------------- |
| Tokyo | `tok` | `https://tok.rpc.orbitflare.com?api_key=YOUR_API_KEY` |
| Singapore | `sgp` | `https://sgp.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)**.
| Plan | Requests per Second (RPS) | Transactions per Second (TPS) |
| --------- | :-----------------------: | :---------------------------: |
| Free | 10 | 1 |
| Developer | 50 | 10 |
| Growth | 200 | 75 |
| Scale | 400 | 150 |
| Pro | 600 | 200 |
| Dedicated | Unlimited | Unlimited |
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)
| Limit | Value |
| ----------------------------- | ----------------------------------- |
| Concurrent connections per IP | **50** |
| Subscriptions per connection | Unlimited |
| Idle connection timeout | 10 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:
```typescript theme={null}
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
| Limit | Value |
| ----------------------------- | ---------------------------- |
| Concurrent connections per IP | **50** |
| Subscriptions per connection | Varies by plan |
| Idle connection timeout | 60 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](https://discord.gg/orbitflare) 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.