> ## 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 an entire hourly batch of fixtures > Fixture data is grouped into hourly batches. Each batch is represented by a Merkle Tree, and its root hash is published on-chain. This Merkle root is contained within the batch's metadata. This endpoint allows you to validate the integrity of the batch metadata itself. It returns the metadata for the specified hourly batch, along with a Merkle proof. A user can take this proof and the metadata (which includes the final Merkle root) and use it to verify against a higher-level tree or commitment, thus cryptographically proving the integrity of the entire batch's claimed state. ## OpenAPI ````yaml https://txline.txodds.com/docs/docs.yaml get /api/fixtures/batch-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/batch-validation: get: tags: - Fixtures summary: Get a Merkle proof for an entire hourly batch of fixtures description: > Fixture data is grouped into hourly batches. Each batch is represented by a Merkle Tree, and its root hash is published on-chain. This Merkle root is contained within the batch's metadata. This endpoint allows you to validate the integrity of the batch metadata itself. It returns the metadata for the specified hourly batch, along with a Merkle proof. A user can take this proof and the metadata (which includes the final Merkle root) and use it to verify against a higher-level tree or commitment, thus cryptographically proving the integrity of the entire batch's claimed state. operationId: getApiFixturesBatch-validation 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: epochDay in: query description: The day since the Unix epoch for the desired batch. required: true schema: type: integer - name: hourOfDay in: query description: The hour of the day (UTC, 0-23) for the desired batch. required: true schema: type: integer responses: '200': description: '' content: application/json: schema: $ref: '#/components/schemas/FixtureBatchValidation' '400': description: >- Invalid value for: header Authorization, Invalid value for: header X-Api-Token, Invalid value for: query parameter epochDay, Invalid value for: query parameter hourOfDay 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: FixtureBatchValidation: title: FixtureBatchValidation type: object required: - metadata - proof properties: metadata: $ref: '#/components/schemas/BatchMetadata' proof: $ref: '#/components/schemas/List_ProofNode' BatchMetadata: title: BatchMetadata type: object required: - totalUpdateCount - numUniqueFixtures - overallBatchStartTs - overallBatchEndTs properties: totalUpdateCount: type: integer format: int32 numUniqueFixtures: type: integer format: int32 overallBatchStartTs: type: integer format: int64 overallBatchEndTs: type: integer format: int64 List_ProofNode: title: List_ProofNode oneOf: - $ref: '#/components/schemas/Nil' - type: array items: $ref: '#/components/schemas/ProofNode' 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 ````