Skip to main content
Version: v1

Treasures Finance B2B Public API

Public B2B API for tokenized stock discovery, quoting and trade execution, USDC bridging across Solana and Ethereum, and portfolio + trade history reads.

Wire format. All token amounts, USDC amounts, shares, prices and bps-derived decimals are JSON strings to avoid float drift. Integer fields (expires_at, *_bps, quote_index, timestamps in seconds) are JSON numbers.

Auth. Only POST /quote/buy, POST /quote/sell and POST /bridge/quote require ownership_proof (wallet-key signature over a canonical challenge, see OwnershipProof). POST /trade/submit is gated by the per-leg signed payload itself. These routes require an integrator API key in X-API-Key (see IntegratorApiKey): GET /settlements, the /payouts routes (your integrator fees and their payouts), POST /quote/preview (which binds no wallet, so the key is what identifies the caller) and GET /stocks/{ticker} (whose profile, analyst, earnings and news blocks are served to contracted integrators only). Every other route may be called anonymously.

Integrator API keys are optional on every route but those, and never ignored. If you send X-API-Key on any route, a key beginning tik_/trk_ is verified and a bad one is rejected rather than silently downgraded to anonymous:

ConditionResponse
Malformed or unknown key401 invalid_api_key
Revoked key403 key_revoked
Your organisation is suspended403 integrator_suspended
Read-only (trk_) key on a non-reporting route403 insufficient_scope

A trk_ reporting key reaches the reporting routes and nothing else. Today that is exactly one route: GET /settlements. Everywhere else on this API it answers 403 insufficient_scope. That refusal is the point: it is what makes the key safe to hand to a third party for reporting. Use your tik_ key for API access; it works on the reporting routes too. A credential for a different Treasures plane (e.g. a twk_ wallet key) is not addressed to this API and is ignored, so those requests are served anonymously.

Rate limits. Per-IP and per-(IP, wallet) sliding windows. Presenting a valid key adds a per-organisation bucket shared by all of your keys, a cross-IP aggregate bound, additive to the per-IP limits rather than a raised ceiling. Upstream 429s propagate as 502 provider_unavailable.

Authentication​

Per-organisation key issued out of band. Two kinds: tik_… (general: API access) and trk_… (reporting: read-only, intended to be handed to a third party, and accepted only on the reporting routes: today just GET /settlements. Every other route in this spec answers insufficient_scope). Required by GET /settlements, by the /payouts routes, by POST /quote/preview and by GET /stocks/{ticker} (all but /settlements take a general tik_ key only, being non-reporting routes); accepted on every other route for attribution and a per-organisation rate bucket. Send it on POST /trade/submit too; that is what makes a trade appear in your GET /settlements reporting. A missing or unknown key is 401 invalid_api_key; a real but retired key is 403 key_revoked.

Security Scheme Type:

apiKey

Header parameter name:

X-API-Key