Authentication

Use an API key beginning with usq_live_ for prepaid balance, or submit without one when the signed transaction contains the exact payment returned by /v1/pricing.

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 malformed or unknown key returns 401 INVALID_API_KEY. A missing header is allowed only when the signed transaction contains the exact in-transaction payment described below; otherwise it returns402 PAYMENT_REQUIRED.

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.

Without an API key#

Read https://send.swqos.com/v1/pricing, then include one canonical System Program transfer for exactly in_transaction_payment_lamports to in_transaction_payment_recipient in the transaction you sign. Submit the exact signed bytes without a bearer key or prepaid balance.

This mode has no separate refund. If the transaction does not execute, the payment transfer does not execute, so no SOL leaves your wallet. If it executes, the transfer and your other instructions execute atomically. The relay verifies the signature, recipient, exact amount, writable accounts and signer before forwarding.

Reading your account#

Authenticate against /v1/account to read your balance, default tip, account markup and whether the account is enabled. This is the authoritative view because account markup can differ from the public default.

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#   "default_tip_lamports": 100000,
11#   "tip_markup_bps": 5000
12# }

balance_lamports / 1e9 is your balance in SOL. The default charge is the default tip plus the percentage in tip_markup_bps; one percent is 100 basis points.

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.