Access & authentication

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 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://:

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);

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. Everything on the wire is readable, API keys in query strings and x-token metadata included.

Access methods

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. 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.

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:

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.<region>.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.

Diagnose access failures

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 and we'll rotate it.