📢 The Ask AI can now translate any part of the docs to your preferred language!
Read the guide
sportradar.comSportradar Support Portal

Examples

The SDK release includes 10 runnable .NET Examples to help you get started quickly with the Unified Odds Feed SDK. These examples demonstrate common integration scenarios and provide a hands-on way to explore the SDK’s functionality.

While the original examples were provided in Java, this guide focuses on .NET. You can run the examples using Visual Studio, Visual Studio Code, or the CLI.

Prerequisites

Before you start with these examples, ensure you have:

1. Development Environment

  • Visual Studio (preferred) or Visual Studio Code.

  • .NET 6.0 or higher installed.

2. Project Setup

  • Access to the Unified Odds Feed .NET SDK project files.

  • Knowledge of building .NET projects from the CLI if you plan to use commands like dotnet build or dotnet run.

3. Access Credentials

  • A valid integration token to connect to the Unified Odds Feed.

4. Basic Knowledge

  • Familiarity with C# programming concepts.

  • Understanding of SDK initialization and running simple .NET programs.

Project Structure

Available Examples

You can choose from the following examples when starting the SDK. Each example demonstrates a specific usage pattern or architecture for working with the Unified Odds SDK.

Watch the video below ⤵️ for a quick walkthrough on how to run these examples in Visual Studio Code (VS Code).

Running the Example

To test the SDK examples, select the corresponding number from the list displayed in the terminal. As shown in the image below, there are nine examples (1–9), each representing a specific functionality of the SDK.

When prompted with “Enter number:”, type the number of the example you want to run. For instance:

  • To run the Multi-Session example, enter 2.

  • To display Market Info, enter 4.

  • Repeat this process for any other example you wish to test.

Use the image above as a reference to understand what each number represents before making your selection.

1. Basic SDK Setup

This example uses a single UofSession configured with MessageInterest.AllMessages, enabling full odds recovery from all producers. It focuses on SDK initialization and how to handle global and message-level events.

Response:

2. Multi-Session Architecture

In this setup, two parallel sessions are created, one with high priority and another with low priority. It highlights how to isolate sessions, filter messages based on priority, and handle events concurrently.

Response:

3. Event Type-Specific Handlers

Here, a single session is used, but each sport event type (such as Match, Stage, or Tournament) has its own dedicated handler. This pattern is ideal for processing different event types separately with custom logic.

Response:

4. Market Information

This example displays market data contained in each incoming message. It helps you explore market metadata and understand how market and outcome structures are represented in the feed.

Response:

5. Sport Event Information

In this example, each incoming message is enriched with SportEvent details. It demonstrates the SportEvent hierarchy and how to access related API calls for retrieving detailed event information.

Response:

6. Complete Information

This combines both market and sport event data in a single session. It also shows how to limit recovery using timestamps and provides deeper insights into market metadata, outcome structures, and the SportEvent hierarchy.

Response:

7. Extra: Market Mapping Information

An additional example that focuses on market mappings. It shows how to access MarketMapping metadata, including specifiers and structure details for each market received.

Response:

8. Extra: Replay Server

This example connects the SDK to the Replay Server. It allows you to replay previous sport events or entire scenarios, making it useful for testing integrations with historical data.

Response:

9. Extra: Cache Export / Import

This setup demonstrates how to serialize and deserialize the SDK cache to persist state across restarts. It’s useful for managing cache data, maintaining state, and optimizing performance.

Response:

PreviousOutcomesNextCommon Logs Explained

Last updated

Was this helpful?