Authentication

Requests without a valid key are rejected up front: gRPC calls fail with UNAUTHENTICATED, HTTPS surfaces return 401. If your very first grpcurl list fails, check the key before anything else.

Attach the key as call metadata on every RPC. Metadata rides the initial HTTP/2 headers, so long-lived streams authenticate once at connect time.

grpcurl -H 'x-api-key: YOUR_KEY' stream.hyperliquidrpc.com:443 list

RPC, /info, and the historical query API take the same key as a plain request header:

# HyperEVM JSON-RPCcurl https://rpc.hyperliquidrpc.com -H 'x-api-key: YOUR_KEY' \  -H 'content-type: application/json' \  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' # HyperCore /infocurl https://api.hyperliquidrpc.com/info -H 'x-api-key: YOUR_KEY' \  -H 'content-type: application/json' \  -d '{"type":"meta"}'

• Keep keys in environment variables or a secret manager — never in source control, never in client-side code. A leaked key spends your egress and request quota.
• Use separate keys per service and per environment (staging vs. production), so a single revocation never takes down everything at once. Paid tiers include multiple keys — see rate limits & tiers.
• Browser dashboards should proxy through your backend. gRPC streams are server-to-server; do not embed a key in shipped frontend code.
• Usage is attributed per key in the console, so one key per consumer also gives you per-consumer metering for free.

Rotation is zero-downtime if you sequence it:

• Create the replacement key in the console.
• Deploy consumers with the new key. Long-lived streams pick it up on their next reconnect — force one if you want the cutover now.
• Revoke the old key. New connections with it are rejected from that point, so rotate first, revoke second.