---
title: "List the QR/transfer token shortlist"
method: GET
path: "/qr/tokens"
tags: ["Utilities"]
---

# List the QR/transfer token shortlist

`GET /qr/tokens`

Returns the curated per-chain token shortlist the QR / manual-transfer flow offers as "what are you sending?". That flow has no connected wallet to read balances from, so it needs a suggested set rather than a discovered one. Filtered against the authenticated project's `depositWhitelist` when one is configured, so the flow cannot offer a token the client would reject on arrival. This is a suggestion list, not a capability list — `/chains` remains the authority on what the service supports.

## Headers

- `x-api-key` string — API key for authentication (omit when sending Authorization)
- `authorization` string — Bearer platform token (e.g. forwarded by user-service). Takes precedence over `x-api-key` when both are present.

## Response `200`

Token shortlist per chain

- QrTokensResponse
  - `tokens` object, required — Keyed by EVM chain id as a decimal string, plus "solana" and "hypercore". An empty array means the deposit whitelist disallows this chain entirely — clients should hide it rather than offer a chain with nothing to send, and it is reported even for chains this shortlist does not curate. An absent chain carries no opinion (it is allowed, but no shortlist is curated for it) and clients should keep whatever default they have for it; the two are not interchangeable.

## Other responses

- `401` — Authentication required
- `403` — API key lacks required deposits scope

---

[API](https://skmtc.net/rhinestonewtf/apis/deposit-service-api.md) · [All operations](https://skmtc.net/rhinestonewtf/apis/deposit-service-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/rhinestonewtf/deposit-service-api/revisions/c9aa3f252e4f/schema)