> ## Documentation Index > Fetch the complete documentation index at: https://docs.totalis.trade/llms.txt > Use this file to discover all available pages before exploring further. # Get vault > The caller's vault state and active position summaries. ## OpenAPI ````yaml GET /v1/vault openapi: 3.0.3 info: title: Totalis RFQ API version: 2.1.0 description: >- Public REST surface for the Totalis parlay RFQ platform, a decentralized request-for-quote marketplace for parlay bets across Kalshi and Polymarket, with on-chain Solana vault settlement. **Wire format**: snake_case JSON. All successful responses are wrapped in `{ "data": ... }`; list endpoints add `meta` with cursor-based pagination. Errors use a `{ "error": { code, message, details? } }` envelope. **Authentication**: programmatic clients send `X-API-Key`; the web dashboard uses Privy JWTs (`Authorization: Bearer ...`). Any authenticated user can both place parlays and quote as a market maker. There is no separate MM role. Admin endpoints are out of scope for this public reference. **Rate limiting**: three buckets. Authenticated routes share one per-account bucket of 300 req/min (100 without a key). Public market reads (`/markets`, `/v1/markets`) are a separate per-IP bucket of 100 req/min that an API key does not raise. Quote service routes (`/v1/quote-requests`, `/v1/cashout-requests`, `/v1/mm/quote-requests`, `/v1/mm/cashout-requests`) have their own per-IP limit, 300 req/min by default. Responses include `X-RateLimit-*` headers. Request body limit: 256KB. **Pagination**: list endpoints use opaque cursor pagination. Pass `meta.cursor` from the previous response as `?cursor=...` to fetch the next page; do not parse or construct cursors client-side. servers: - url: https://api.totalis.trade description: Production security: - ApiKey: [] tags: - name: Markets description: Cached Kalshi and Polymarket market data. - name: User description: User profile, wallet, and devnet helpers. - name: API Keys description: Manage programmatic access keys for the authenticated user. paths: /v1/vault: get: tags: - Vault summary: Get user vault state and active positions description: > Returns the user's vault balance and active positions. Returns data: null (200 OK) if the user has no vault yet (the vault is created with your first filled position). operationId: getUserVault responses: '200': description: OK. Vault state or null if no vault exists content: application/json: schema: type: object properties: data: nullable: true allOf: - $ref: '#/components/schemas/UserVaultResponse' security: - PrivyJWT: [] - ApiKey: [] components: schemas: UserVaultResponse: type: object description: >- Your vault and its active positions. A wallet has one on-chain vault, which backs both your bets and your quotes. `positions` lists your bettor-side positions, or your maker-side ones if you have never placed a bet. properties: vault_pda: type: string vault_token_account: type: string gross_balance: type: number locked_collateral: type: number free_balance: type: number positions: type: array items: $ref: '#/components/schemas/VaultPositionSummary' VaultPositionSummary: type: object description: | Lightweight position summary for the vault response. Caller-relative reading: `user_stake` and `mm_risk` are side-of-trade labels, not caller-relative ones. When `UserVaultResponse` returns the bettor-side vault, `user_stake` is the caller's own stake. When it returns the maker-side vault (pure-MM accounts), `user_stake` is the counterparty bettor's stake and `mm_risk` is the caller's own collateral. Don't display `user_stake` as "my stake" without branching on which vault was returned. For aggregate "USDC committed", prefer `wallet.locked_amount`, which is role-agnostic. properties: position_id: type: string description: 16-byte position ID (hex encoded) rfq_id: type: string format: uuid user_stake: type: number description: | Bettor side of the trade. The caller's stake on the bettor-side vault response; the counterparty's stake on the maker-side vault response. mm_risk: type: number description: | Maker side of the trade. The counterparty's collateral on the bettor-side vault response; the caller's own collateral on the maker-side vault response. total_payout: type: number status: $ref: '#/components/schemas/PositionStatus' created_at: type: string format: date-time PositionStatus: type: string description: >- Vault position lifecycle. `pending`/`processing` are intermediate states before on-chain creation; `settling`/`cancelling` are intermediate states for settlement/cancellation; `settled_win`/`settled_loss`/`cancelled` are terminal; the `*_mm_release` and `expired` states cover the permissionless-expiry path; the buyback path is `active` to `bought_back_pending_db` to `bought_back` (with `reconciling_bought_back_db` as a short-lived transient state in which collateral is still held); `error` means retries are exhausted and manual intervention is required. enum: - pending - processing - active - settling - cancelling - settled_win - settled_loss - cancelled - reconciling_mm_release - expired_pending_mm_release - expired - reconciling_bought_back_db - bought_back_pending_db - bought_back - error securitySchemes: ApiKey: type: apiKey in: header name: X-API-Key description: >- Programmatic API key. Sent as `X-API-Key: `. Generate one from the Totalis dashboard. The WebSocket takes no header; send the key in the auth message instead. PrivyJWT: type: http scheme: bearer bearerFormat: JWT description: >- Privy JWT issued to the web dashboard. Sent as `Authorization: Bearer `. The Privy session signer underpins all wallet-signed actions. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.