> ## Documentation Index > Fetch the complete documentation index at: https://txline-docs.txodds.com/llms.txt > Use this file to discover all available pages before exploring further. # Get a Merkle proof for a specific odds update > Each odds update is part of a batch whose state is committed to the blockchain via a Merkle root. This endpoint returns the cryptographic proof for a single odds update, identified by its unique messageId. The proof consists of the hashes along the branch of the Merkle tree, which can be used to reconstruct the root. A user can then use this proof and the odds record in an on-chain transaction to cryptographically verify that the odds update was published by the TxODDS Oracle as confirmed by the on-chain Merkle root. ## OpenAPI ````yaml https://txline.txodds.com/docs/docs.yaml get /api/odds/validation openapi: 3.1.0 info: title: TxLINE off-chain API for the Hybrid on-chain/off-chain TxODDS Data system version: 1.5.2 description: > ## Overview This API provides access to real-time and historical sports data from the **TxLINE on-chain/off-chain Data system**. It makes proprietary TxODDS available for any funded blockchain users by linking the on-chain `subscribe` transaction by issuing time-limited API tokens. - The data is canonicalised so that all fixtures, odds, or scores are provably identifiable and ordered--confirmed by on-chain cryptographic proofs. - The data is delivered in a request-response or Server-Sent Events (SSE) streaming form. Examples of accessing the accompanying on-chain program are available publicly at: https://txline.txodds.com/documentation. All data returned by the off-chain API is canonicalised such that every single record can be cryptographically proven on-chain to be part of the unique and consistent dataset generated by the TxODDS Data system. ## Key features * The odds data includes the `Stable Price` demargined prices and percentages, currently for key markets in European football (soccer). * **Free subscription option that offers World Cup 2026 odds and off-the-board signals in real-time sampled every 60 seconds**. * **Data access paid for by the TxLINE token tethered to USDT ata rate 1 USDT = 1_000 TxLINE tokens** The TxLINE utility token can purchased using the associated Solana program. * **Fine-grained service level selection** The user can list the pre-configured **service levels** that either map to pre-defined league bundles or allow custom selecting the leagues explicitly. The price also depends on the sampling period for the data. * **Maximum subscription option that offers all leagues in real-time**. * **Historical Snapshots:** Query the latest state of any market at a specific point in time. * **Historical Updates:** Query the updates for any given key such as fixture or market for a given time period. * **Live Data Streams:** Real-time, low-latency data feeds using Server-Sent Events (SSE). * **On-chain Validation:** Retrieve Merkle proofs to cryptographically verify data against the on-chain held Merkle roots by calling appropriate validate on-chain instructions. ## How do the users gain access to off-chain data (see more details and examples at: https://github.com/txodds/tx-on-chain) 1. For paid service tiers, the user purchases TxODDS TxLINE utility tokens for USDT at a fixed rate using either a script (e.g., calling `purchase_subscription_token_usdt`) or an affiliate website. The tokens are deposited into the user's associated token account. (Note: This step is skipped for the free World Cup tier). 2. As a guest, with no prior authentication, the user calls the off-chain API at "https://txline.txodds.com/auth/guest/start" (or `txline-dev` for DevNet) to obtain an anonymous JWT with Guest claims. **Please note that the JWT token has 30 days expiration so if you are issuing calls to the data endpoints beyond 30 days, you should either pre-acquire a new JWT token in time before 30 days expire or respond to the returned HTTP 401 code by reacquiring a fresh JWT token.** 3. The user creates, signs, and confirms a Solana transaction to the `subscribe` instruction, indicating the duration in weeks (must be a multiple of 4 weeks, e.g. 4, 8, 12) and the chosen service level. The user explicitly acts as the transaction fee payer. For the free tier, the smart contract registers the subscription but charges 0 TxLINE tokens. 4. The user records the confirmed transaction signature (`txSig`). 5. The user constructs a strict message binding consisting of the `txSig`, a comma-separated list of selected leagues, and the JWT. 6. The user cryptographically signs this message using their wallet's secret key to generate a detached signature, which is then Base64-encoded. 7. The user activates the subscription with the off-chain server at "https://txline.txodds.com/api/token/activate" (or `txline-dev` for DevNet) by posting the `txSig`, the Base64 wallet signature, and the selected leagues array, using the JWT for authorization. 8. The off-chain server validates the cryptographic proof and entitlements, issuing an appropriate API Token or rejecting the activation with a reason. 9. The user calls the documented APIs while the subscription is valid, supplying both the JWT and the API Token. 10. Before the subscription expires, the user may call the `subscribe` instruction again to extend the validity period (by a multiple of 4 weeks, e.g. 4, 8, 12) via the same off-chain activation call. The selected leagues can also be amended. 11. If the previous subscription has expired, the user can activate a new API Token by repeating the process. servers: - url: https://txline.txodds.com description: Production TxLINE server - url: http://txline-dev.txodds.com description: Test TxLINE server security: [] paths: /api/odds/validation: get: tags: - Odds summary: Get a Merkle proof for a specific odds update description: > Each odds update is part of a batch whose state is committed to the blockchain via a Merkle root. This endpoint returns the cryptographic proof for a single odds update, identified by its unique messageId. The proof consists of the hashes along the branch of the Merkle tree, which can be used to reconstruct the root. A user can then use this proof and the odds record in an on-chain transaction to cryptographically verify that the odds update was published by the TxODDS Oracle as confirmed by the on-chain Merkle root. operationId: getApiOddsValidation parameters: - name: Authorization in: header description: Bearer token for the user's session JWT. required: true schema: type: string - name: X-Api-Token in: header description: The user's long-lived API token. required: true schema: type: string - name: messageId in: query description: The unique message ID of the odds update to validate. required: true schema: type: string - name: ts in: query description: Timestamp of the odds message. required: true schema: type: integer format: int64 responses: '200': description: '' content: application/json: schema: $ref: '#/components/schemas/OddsValidation' '400': description: >- Invalid value for: header Authorization, Invalid value for: header X-Api-Token, Invalid value for: query parameter messageId, Invalid value for: query parameter ts content: text/plain: schema: type: string '401': description: 'Authorization failed: Invalid or expired guest JWT' content: text/plain: schema: type: string '403': description: 'Access denied: Invalid API token or insufficient permissions' content: text/plain: schema: type: string '500': description: Internal server error content: text/plain: schema: type: string security: - httpAuth: [] apiKeyAuth: [] components: schemas: OddsValidation: title: OddsValidation type: object required: - odds - summary - subTreeProof - mainTreeProof properties: odds: $ref: '#/components/schemas/Odds' summary: $ref: '#/components/schemas/OddsBatchSummary' subTreeProof: $ref: '#/components/schemas/List_ProofNode' mainTreeProof: $ref: '#/components/schemas/List_ProofNode' Odds: title: Odds type: object required: - FixtureId - MessageId - Ts - Bookmaker - BookmakerId - SuperOddsType - InRunning properties: FixtureId: type: integer format: int64 MessageId: type: string Ts: type: integer format: int64 Bookmaker: type: string BookmakerId: type: integer format: int32 SuperOddsType: type: string GameState: type: string InRunning: type: boolean MarketParameters: type: string MarketPeriod: type: string PriceNames: type: array items: type: string Prices: type: array items: type: integer format: int32 OddsBatchSummary: title: OddsBatchSummary type: object required: - fixtureId - updateStats - oddsSubTreeRoot properties: fixtureId: type: integer format: int64 updateStats: $ref: '#/components/schemas/OddsUpdateStats' oddsSubTreeRoot: type: string format: binary List_ProofNode: title: List_ProofNode oneOf: - $ref: '#/components/schemas/Nil' - type: array items: $ref: '#/components/schemas/ProofNode' OddsUpdateStats: title: OddsUpdateStats type: object required: - updateCount - minTimestamp - maxTimestamp properties: updateCount: type: integer format: int32 minTimestamp: type: integer format: int64 maxTimestamp: type: integer format: int64 Nil: title: Nil type: object ProofNode: title: ProofNode type: object required: - hash - isRightSibling properties: hash: type: string format: binary isRightSibling: type: boolean securitySchemes: httpAuth: type: http description: User's session JWT. scheme: bearer apiKeyAuth: type: apiKey description: The user's long-lived API token, obtained from the activation endpoint. name: X-Api-Token in: header ````