Authentication

swqos.com authenticates every request with an API key that begins with usq_live_. Over HTTPS it is a bearer token; over QUIC the client derives a certificate from the same key and presents it during the handshake.

What the key is#

Your API key encodes a real Ed25519 keypair. It is not an opaque lookup string that we check against a table: the relay decodes it, derives the public key, and uses that to find your account. Treat it as a private key, because structurally that is what it is.

What it cannot do is equally worth stating. The key cannot sign your transactions, move SOL out of any wallet, or authorise anything on chain. Its only power is to spend your prepaid balance by submitting transactions.

Over HTTPS#

Send it as a bearer token on every request.

header
1Authorization: Bearer usq_live_...

A missing header returns 401 UNAUTHORIZED. A header that is present but cannot be decoded returns 401 INVALID_API_KEY. The two are separate on purpose, because they mean different things: one is a client that forgot to authenticate, the other is a key that is truncated, stale or from the wrong environment.

Over QUIC#

The QUIC path does not send the key in a header. The client decodes it, builds a Solana-compatible client certificate from the keypair, and presents that during the TLS handshake. The server reads the public key out of the peer certificate and resolves your account once, at connection time, rather than on every submission.

That is part of why the QUIC path is faster: identity is established once for the life of the connection. Connect to send.swqos.com:11000 and see send over QUIC for the stream protocol.

Reading your account#

Authenticate against /v1/account to read your balance, your effective price and whether the account is enabled. This is the authoritative view: an account can carry a price that differs from the public default, and this route reflects it.

account
1curl -sS https://send.swqos.com/v1/account \
2  -H "Authorization: Bearer $SWQOS_API_KEY"
3 
4# {
5#   "account_id": "swqos_a1b2c3d4",
6#   "name": "production",
7#   "public_key": "...",
8#   "balance_lamports": 50000000,
9#   "enabled": true,
10#   "submission_price_lamports": 200000
11# }

Useful conversions: balance_lamports / 1e9 is your balance in SOL, and floor(balance_lamports / submission_price_lamports) is how many more accepted sends you can afford.

Looking after the key#

Never put the key in a URL, a log line, a support ticket, a metrics label, a screenshot, an analytics event, or frontend source. Anything that can spend money should only ever travel in a header from a server you control.
  • Store it in a secrets manager or an environment variable, never in a repository.
  • Give each deployment its own account rather than sharing one key across environments.
  • If a key leaks, email support@swqos.com and we will disable it. Because balances are prepaid, your exposure is capped at whatever is on the account.

The public HTTPS base is https://send.swqos.com. Administrative routes are not reachable from the internet at all, so there is nothing on that hostname that a leaked customer key can escalate into.