# Access & authentication (/platform/access)
> Authenticate to Corvus Solana RPC with an IP allowlist, a tokenized URL or an x-token, over plaintext HTTP, WebSocket and gRPC.
Every endpoint has exactly one access method, and it belongs to the endpoint rather than to your account. Two endpoints can authenticate differently; the [dashboard](https://dashboard.corvus-labs.io) shows which method each uses.
## Transport security
No Corvus endpoint terminates TLS: RPC, WebSocket, Yellowstone gRPC, aRPC and Falcon are all plaintext. The Yellowstone clients (`@triton-one/yellowstone-grpc`, `yellowstone-grpc-client`) pick credentials from the endpoint scheme, so keep the `http://`:
```ts
import Client from '@triton-one/yellowstone-grpc';
// endpoint, x-token (dedicated deployments only), channel options
const client = new Client('http://fra.corvus-labs.io:10101', undefined, undefined);
```
```rust
use yellowstone_grpc_client::GeyserGrpcClient;
// No tls_config() on the builder, so the channel stays plaintext.
let mut client = GeyserGrpcClient::build_from_shared("http://fra.corvus-labs.io:10101")?
.connect()
.await?;
```
aRPC targets follow the same scheme convention; raw-client examples are on [aRPC regions & endpoints](/arpc/regions#pass-the-endpoint-to-a-grpc-client). Everything on the wire is readable, API keys in query strings and `x-token` metadata included.
## Access methods
| Method | Applies to | Mechanism |
| ------------------- | --------------------------------- | ----------------------------------------- |
| IP allowlist | Standard regional endpoints, aRPC | Your registered public egress IP |
| Tokenized URL path | Dedicated HTTP and WebSocket only | Secret path segment in the URL |
| gRPC metadata token | Dedicated gRPC deployments only | `x-token` metadata on the channel or call |
| Falcon API key | All Falcon transports | UUID |
Two rules that catch people out:
* The tokenized-URL method applies **only to the HTTP RPC and WebSocket proxies**. Yellowstone gRPC and aRPC never use it; there is no secret path segment to add to a gRPC target.
* Adding an `x-token` to an endpoint that authenticates by IP grants nothing, and its absence is not the reason a request failed.
## Register your egress IP
Allowlisted addresses are managed in the [dashboard](https://dashboard.corvus-labs.io). We check the public source address we observe, which is not necessarily the address your host thinks it has. Register a stable one (a static egress address or a NAT gateway) so restarts, redeploys and autoscaling don't change it.
```bash
curl --silent https://api.ipify.org
```
Run it from the same host and network path as the RPC client. Behind NAT, that is the address seen outside the network.
## Send an `x-token`
Shared deployments never have one; their credential is the registered egress IP. An `x-token` exists only where a dedicated deployment was configured with one, and it arrives at onboarding.
The Yellowstone client takes the token as its second constructor argument. On a raw client, attach it as metadata on the channel or per call:
```ts
const metadata = new grpc.Metadata();
metadata.set('x-token', process.env.CORVUS_TOKEN);
```
Use the header name exactly as issued. Do not move the token into a query string or an `Authorization` header unless your assigned endpoint requires it.
## aRPC access
aRPC endpoints (`http://arpc..corvus-labs.io:20202`) default to **IP allowlist**. The `x-token` interceptor is a no-op when no token is configured for the endpoint, so a wrong or missing token produces no error there. If aRPC rejects you, check the egress IP first.
## Falcon API keys
Falcon uses a UUID API key on every transport rather than an IP allowlist: `?api-key=` on HTTP, the UUID at connect time for QUIC, and the UUID inside every datagram for native UDP. See [Falcon regions & endpoints](/falcon/regions).
## Diagnose access failures
| Symptom | Cause | Fix |
| ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| HTTP `401`, code `-32002`, `Unauthorized` | Source IP is not registered, or the tokenized path segment is wrong | Verify the observed egress IP from the failing host; re-check the path character for character |
| HTTP `403`, code `-32003`, `You have no access to this service` | Authenticated, but your plan does not include this interface | Compare against your [plan contents](/platform/pricing); reconnecting will not clear it |
| gRPC `UNAUTHENTICATED` (16) | Unregistered egress IP, or a missing or wrong `x-token` on a dedicated token endpoint; gRPC reports both this way | Check the observed egress IP first, then the header name and value |
| gRPC `PERMISSION_DENIED` (7), reason `permission_denied`, detail beginning `PPS limit requirement not met` | Streaming access requirement not met on that endpoint. **The server then shuts the connection down.** | Not retryable; the same reconnect will be rejected. See [errors](/solana-rpc/errors#pps-limit-requirement-not-met) |
| Works locally, fails in production | Different egress IP or proxy/NAT path | Register the production egress IP |
| Fails intermittently | Rotating egress addresses, or a credential replaced mid-deploy | Pin egress; deploy credentials atomically |
`401`, `403`, `UNAUTHENTICATED` and `PERMISSION_DENIED` are configuration states. Nothing changes until the configuration does, so do not retry them in a loop.
A tokenized URL logged in full is a leaked credential. Redact secret path segments and `x-token` values from logs, traces, support screenshots and exception messages. If anything reached a public log or repository, ask us on [Discord](https://discord.gg/corvus-labs) and we'll rotate it.