> ## 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 fixture update > Each fixture returned or referenced in the TxODDS Oracle API is part of an hourly batch of fixture updates. Blockchain holds the Merkle root (ultimate cryptographic containment proof) of each fixture belonging to that batch. This endpoint returns the Merkle proof, i.e., the hashes along the branch of the Merkle tree for the batch up to but not inclusive of that Merkle root. The user can then call on-chain validation directly to get a cryptographic validation that a given fixture update was published by TxODDS as confirmed by the published Merkle root. This on-chain transaction requires the fixture record and the Merkle proof returned here. ## OpenAPI ````yaml https://txline.txodds.com/docs/docs.yaml get /api/fixtures/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/fixtures/validation: get: tags: - Fixtures summary: Get a Merkle proof for a specific fixture update description: > Each fixture returned or referenced in the TxODDS Oracle API is part of an hourly batch of fixture updates. Blockchain holds the Merkle root (ultimate cryptographic containment proof) of each fixture belonging to that batch. This endpoint returns the Merkle proof, i.e., the hashes along the branch of the Merkle tree for the batch up to but not inclusive of that Merkle root. The user can then call on-chain validation directly to get a cryptographic validation that a given fixture update was published by TxODDS as confirmed by the published Merkle root. This on-chain transaction requires the fixture record and the Merkle proof returned here. operationId: getApiFixturesValidation 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: fixtureId in: query description: The ID of the fixture to validate. required: true schema: type: integer format: int64 - name: timestamp in: query description: >- Optional. A Unix timestamp (ms) to get the validation proof for a specific point in time. Defaults to now. required: false schema: type: integer format: int64 responses: '200': description: '' content: application/json: schema: $ref: '#/components/schemas/FixtureValidation' '400': description: >- Invalid value for: header Authorization, Invalid value for: header X-Api-Token, Invalid value for: query parameter fixtureId, Invalid value for: query parameter timestamp 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: FixtureValidation: title: FixtureValidation type: object required: - snapshot - summary - subTreeProof - mainTreeProof properties: snapshot: $ref: '#/components/schemas/Fixture' summary: $ref: '#/components/schemas/FixtureBatchSummary' subTreeProof: $ref: '#/components/schemas/List_ProofNode' mainTreeProof: $ref: '#/components/schemas/List_ProofNode' Fixture: title: Fixture type: object required: - Ts - StartTime - Competition - CompetitionId - FixtureGroupId - Participant1Id - Participant1 - Participant2Id - Participant2 - FixtureId - Participant1IsHome properties: Ts: type: integer format: int64 StartTime: type: integer format: int64 Competition: type: string CompetitionId: type: integer format: int32 FixtureGroupId: type: integer format: int32 Participant1Id: type: integer format: int32 Participant1: type: string Participant2Id: type: integer format: int32 Participant2: type: string FixtureId: type: integer format: int64 Participant1IsHome: type: boolean FixtureBatchSummary: title: FixtureBatchSummary type: object required: - fixtureId - competitionId - competition - updateStats - updateSubTreeRoot properties: fixtureId: type: integer format: int64 competitionId: type: integer format: int32 competition: type: string updateStats: $ref: '#/components/schemas/FixtureUpdateStats' updateSubTreeRoot: type: string format: binary List_ProofNode: title: List_ProofNode oneOf: - $ref: '#/components/schemas/Nil' - type: array items: $ref: '#/components/schemas/ProofNode' FixtureUpdateStats: title: FixtureUpdateStats 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 ````