FAQ

Please review below FAQ's for any related questions you may have.

What happens if a client disconnects before markets are settled/suspended?

The client receives a full image on reconnection which overwrites all older prices. The client will need to process the market message for every market, and the market_update message for every market that matches their subscription.

When are old events purged from the feed?

Old tournaments hang around for 7 days currently to keep the results around. Obviously our prices will disappear earlier.

What happens when my application disconnects, and reconnection is established after bets have been settled?

You will receive settlement information for that event.

Will I receive old prices when reconnecting after a broken connection?

Subscriptions are not shared between connections. In a scenario of a reconnect, you will receive a market message with all the markets available just as you do when you initialize a connection. You then must re-subscribe to the markets. Once you have re-subscribed you will receive a market_update for all the markets which match your subscriptions. Each connection is independent and does not hold memory of its previous connection.

For dead heat settlement, are you going to use fraction or decimal values for stake and payout?

We won't send fractions, we'll send decimals (like in the example), but that's the correct structure. "settlement": { "stake_returned":0.0, "payout_returned": 0.5 },

Removing a Market

Elaborating question: If you want to "remove" a market created with the following "market" message: "type": "market", "id": "golf_14754_threeball_hole~7cgolfer_ids~3d24~2c1544~2c1548~7chole_num~3d1~7cround_num~3d1", Will you send this? "type": "remove_markets", "msg": ["golf_14754_threeball_hole~7cgolfer_ids~3d24~2c1544~2c1548~7chole_num~3d1~7cround_num~3d1"] or this: "type": "remove_markets", "msg": ["golf_14754_threeball_hole"] To answer this: Every market message will have a property called ID. Let's say that this property is of type MarketID. It's a "slug", which is defined in the documentation: “A slug is defined as a string which may only contain the following characters: digits 0-9, a-z and A-Z, hyphen (-), underscore (_), period (.), and tilde (~). A slug is represented equivalently in ASCII or UTF-8 and may be used in URLs without escaping.” A market's id property is globally unique - we will never re-use them. The msg property of the remove_markets message has type List[MarketID]. Each ID we send will refer to either one or zero markets that we've sent market messages for. The zero there is because it's possible that we would send a remove_markets message for a market we hadn't sent a market message for. We don't expect this ever to actually happen in practice though. Also note that markets are part of a hierarchy. Every market has a parent event, and every event a parent competition. If we send a remove_events message, then any market which belongs to those events should also be removed by that message.

Why is the feed not populating the start_time property for a pre_play market message?

Start time for Markets is always null. That's never set. We do set the start time for events which is dependent on when the Tee Times become available.

Which Tags can I subscribe to?

(COMING SOON) You can subscribe to any combination of tags (sport, competition, event, and market type), but the additive nature means that multiple subscriptions are not usually required.

Some examples:

• ["sp.golf"] will subscribe to all golf markets

• ["comp.golf_pga"] subscribes to all PGA Tour golf markets

• ["ev.golf_14586"] will subscribe to all markets from event ev.golf_14586

• ["ev.golf_14586", "mt.twoball"] will subscribe to all markets from event ev.golf_14586, and also all markets (from any event) of type mt.twoball

Should we expect to continue receiving Odds after the tournament ends?

We would expect our odds to automatically suspend before the tournament officially ends.

We have noticed that within the market_update feed, under the selection_updates the price is returned as 0/1. Is this expected? Should we suspend markets in this case?

That usually happens when a selection does not have a legitimate price for some reason. When it happens, the selection itself should either be settled or suspended

Do we only provide odds for a player making the cut?

That's correct. We don't offer odds that a player won't make the cut to minimise the integrity risks to the sport .

Is there a way to see which market types will be offered for a particular event?

The market reports are the best way to tell. As a rule, Mustard will create all markets which are appropriate for that event type (L1, L2 etc)

Currently after we connect, we send the following command: {"request": "init","msg": {"tags": ["sp.golf", "comp.golf_europga", "ev.golf_14759","mt.threeball_hole"]}}. We expected this to return all 3-ball markets for The Genesis Invitational however it seems we get all markets back. Can you advise if we are requesting 3 ball markets correctly?Do we only provide odds for a player making the cut?

You'll receive the union of the markets which match your subscription, not the intersection: if you subscribe to "ev.golf_7" and "mt.outright", you'll get all markets for event ID 7, and any market of type "mt.outright", rather than markets of type "mt.outright" in event 7.

Currently, it's not possible to subscribe to all markets of a particular type within a particular event.

What are the possible ways a client can subscribe to a market?

They can subscribe to any combination of tags (sport, competition, event, and market type), but the additive nature means that multiple subscriptions are not usually required.

Some examples:

["sp.golf"] will subscribe to all golf markets

["comp.golf_pga"] subscribes to all PGA Tour golf markets

["ev.golf_14586"] will subscribe to all markets from event ev.golf_14586

["ev.golf_14586", "mt.twoball"] will subscribe to all markets from event ev.golf_14586, and also all markets (from any event) of type mt.twoball

We noticed that an initial market_update returned with 3 selections, then another one with just one; changing the price for one selection - is this expected? (logs below)

2021-02-19 20:25:50.421 [main] INFO ssh_traffic:26 - {"mode":"push","type":"market_update","msg":[{"id":"golf_14759_threeball_hole~7cgolfer_ids~3d547~2c4787~2c5179~7chole_num~3d9~7cround_num~3d2","status":"active","ew_terms":null,"meta":{"group_id":11,"hole_num":9,"round_num":2,"event_id":"254"},"selection_updates":[{"display":true,"id":"g:547","meta":{"golfer_id":3397},"name":"Cameron

Tringale","note":"","order":1,"price":"13/8","reason":"","status":"active"},{"display":true,"id":"g:4787","meta":{"golfer_id":3402},"name":"Joel Dahmen","note":"","order":2,"price":"19/10","reason":"","status":"active"},{"display":true,"id":"g:5179","meta":{"golfer_id":7451},"name":"Will Zalatoris","note":"","order":0,"price":"13/8","reason":"","status":"active"}],"display":true,"related_place_markets":null}]}

2021-02-19 20:26:02.295 [main] INFO ssh_traffic:26 - {"mode":"push","type":"market_update","msg":[{"id":"golf_14759_threeball_hole~7cgolfer_ids~3d547~2c4787~2c5179~7chole_num~3d9~7cround_num~3d2","status":"active","ew_terms":null,"meta":{"group_id":11,"hole_num":9,"round_num":2,"event_id":"254"},"selection_updates":[{"id":"g:4787","price":"9/5"}],"display":true,"related_place_markets":null}]}

Yes, this is expected. As explained in https://docs.imgarena.com/mustard-systems-odds-distribution-service/-MKdexAVg8N0obU0S5dH/odds-distribution-service/feed-specification#market-status-update, the selection_updates field will only contain selections that have changed.

When will markets be sent to us?

Markets cannot be generated until static data is received i.e. tee times.

How many concurrent connections can a client have over SSH?

2 connections per customer to each environment.

How can I subscribe to a subset of markets?

(COMING SOON) A subscription is a set of tags. A tag can be a competition, event, market type, or market id. If multiple tags are provided, you will receive markets that match any of the provided tags. For example, "tags": ["ev.golf_1", "mt.outright"] will provide both "all markets for ev.golf_1" and "all markets of type mt.outright"

Why aren't I receiving messages for this market?

This may be because the market does not match your subscription - please note that each session can only have one subscription at time, for example, subscribing to ev.golf_2 after previously subscribing to ev.golf_1 will mean you no longer get markets from ev.golf_1.

This may also be because the market is not available for that event. If you think you should be receiving a market but aren't, please provide your session ID along with the subscription message that are you using

I got a market_update message but some selections were missing?

Only the first market_update message will necessarily contain every selection. Future messages will only contain deltas, for example if only one selection changes, the update message will only contain that selection.

What does resulting data look like? What does a dead heat look like?

There are two fields: stake_returned and payout_returned. Both will be decimals between 0.0 and 1.0 inclusive. A losing selection will have 0.0 for both stake and pay out returned. A winning selection will typically have 0.0 stake and 1.0 pay out. If two selections dead-heat, they will both get 0.5 for payout_returned. A void selection would get 1.0 stake and 0.0 pay out.

How do we result each-way markets?

Results are provided for the main market and the related place market independently. Clients are responsible for using these accordingly. This is because each-way terms can change during the lifecycle of a market. Related place markets are published as a dictionary in the market_update message, for example "related_place_markets": {"4": "golf_123_topn7cnplaces3d4"]"} means that the results for 4 places can be found in the market golf_123_topn7cnplaces3d4.

What is a "related place market"?

Some markets will offer each-way terms. Depending on the each-way settings (e.g. 4 places or 5 places), clients will need to look at more than just the main market to settle customer bets. For example, if the main outright market has each-way settings for 4 places, the related place market would be the "Top 4" market. A customer's bet on selection S would depend on that selection's result in both the main outright and the related place markets. Related place markets are published as a dictionary in the market_update message, for example "related_place_markets": {"4": "golf_123_topn7cnplaces3d4"]"} means that the results for 4 places can be found in the market golf_123_topn7cnplaces3d4.

Are the each-way terms static, or do you update them as the tournament goes on? Also, for the Alternative each way, do the each-way terms update as the tournament goes on or do they remain static for a period of time and then are removed from the offering?

‘Top Region’ markets have moving EW terms so these are updated throughout the tournament to give the correct offering for the changes in the market. The ‘Alternate EW’ markets have static EW terms which don’t change at any point during the tournament.

What happens in the situation where a tournament does to a Playoff?

For playoffs, it is high priority to maintain a Win Only through a playoff. Other markets can be added once we are through the high and medium priority markets (and we can work together on defining a good set of micro-esque markets for the offering). Feedback on this is welcome!

What is happening with tournament and player ids in the new IMGA/DL service once Mustard cease to exist?

Following the imminent delivery of the NEW DL Trading / IMGA Pricing Service, we wanted to let you know that whilst we endeavour to keep the format/structure of the market messages the same and provide a similar service to Mustard for phase 1, we will be replacing all Mustard ids (tournaments/players) with IMGA (DDE Ids) for those directly integrated with the backend SSH Mustard service already from 15^th May. For those integrated with the OpenBet Trading System Platform from a game state point of view, the participants will have an OpenBet Id. Given the current contract between IMG and Mustard is due to terminate on 12^th August we are left with little choice but to replace the Id set.

To help aid that id mapping process (for those it might affect), please find below a mappings file of IMGA DDE Ids vs Mustard Ids. For those using the DDE REST API service already to obtain the player and tournaments Id information e.g. /golf/players REST API or /golf/tournaments/{id} , these APIs will remain unchanged but now these ids will also be inserted into the pricing service. For those who would wish to be licenced, please let us know.

**Please note this only affects the IMGA/DL pricing service whereas the Mustard service will remain unaffected through until 12^th August termination. More info and samples were shared W/C 5th May.

80KB

Mustard - IMGA DDE Ids.csv

Open

Why are there differences between market id & selection id messages in market update messages between DL/IMGA & Mustard?

There are some small differences in the market id market_update message values because working between IMGA and DL we wanted to be more explicit, more pragmatic, and more rigorous than what had been built by Mustard many years back. The Mustard's ids (market ids) are parsable; but it's a bit "approximative" at times and it felt like we wanted to clean this up.

Example Before (Mustard) - "golf_30453_rndlead|round_num=2"

Example After (IMGA/DL Trading) - tid:1115|mt:ROUND_LEADER_EACH_WAY|r:2

This table documents the structure of a market ID, breaking it down into its constituent fields. For each field, it provides:

fieldName: The unique identifier for the field within the market ID.

description: A brief explanation of what the field represents.

type: Indicates whether the field's value is a single entry or a comma-separated list.

exampleValue: A sample value demonstrating the field's format.

This overview helps in understanding how market IDs are composed and the meaning of each component

A selection identifier is a unique string used to precisely define a specific betting outcome within a market. It is structured as a pipe-separated list of key-value pairs, where each pair is colon-delimited (e.g., key:value). The possible sections (keys) and their meanings are:

• pid: Player ID – Identifies the specific player or players associated with the selection.

• t: Type of Selection – Defines the category or nature of the betting outcome. Its value varies based on the market type:

  • BIRDIE_OR_BETTER, PAR, BOGEY_OR_WORSE: Used for markets concerning scores on individual holes.

  • OVER, UNDER: Used in over/under-style betting markets.

  • YES, NO: Used for binary (yes/no) proposition markets.

  • PLAYOFF, SHOTS_1, SHOTS_2, SHOTS_3, SHOTS_4_PLUS: Used for markets relating to winning margins.

  • TIE: Used specifically in head-to-head markets when a tie outcome is offered.

  • PLAYER1, PLAYER2: Used in head-to-head markets to distinguish between the two competing players.

  • PLAYER: A generic identifier for a player in markets that are not head-to-head (e.g., outright winner, Top N).

• v: Line – Indicates a specific value or line, typically used in over/under-like markets (e.g., v:8.5000).

Examples:

• t:BIRDIE_OR_BETTER|pid:10092

• t:BOGEY_OR_WORSE|pid:10092

• t:NO

• t:OVER|v:0.5000|pid:10092

• t:PAR|pid:10092

• t:PLAYER1|pid:108

• t:PLAYER2|pid:134

• t:PLAYER|pid:10092

• t:PLAYOFF

• t:SHOTS_1

• t:TIE

• t:UNDER|v:0.5000|pid:10092

Connectivity and subscription troubleshooting with the new IMGA/DL Service

Below is steps we have put together to help in this setup process and some code sample that works. By default, it connects to IMGA staging env, with user test_user_1 , clients just need to change PRIVATE_KEY_PATH value so it points to their actual private key file location. If they decide to use private key for their 'x' user instead, they obviously have to modify USER accordingly as well.

Running this code will result in

• connection to specified server

• sending init message

• sending subscribe message

• receiving and printing out all messages

Please be aware this is not production ready code, it's just an POC of how to connect to our distribution service.

package org.example;

import org.apache.sshd.client.SshClient;
import org.apache.sshd.common.keyprovider.FileKeyPairProvider;

import java.io.*;
import java.nio.charset.StandardCharsets;
import java.nio.file.Paths;
import java.security.KeyPair;

public class Main {

    public static void main(String[] args) throws Exception {
        var ssh = new TestSshClient();
        ssh.connect();
        ssh.sendMessage("{\"request\":\"init\",\"msg\":{}}");
        ssh.sendMessage("{\"request\":\"subscribe\",\"msg\":{}}");
        ssh.readMessages();
    }
}

class TestSshClient {
    private static final String HOST = "golf-odds-distribution.staging.imgarena.dev";
    private static final Integer PORT = 22;
    private static final String USER = "test_user_1";
    private static final String PRIVATE_KEY_PATH = "/path/to/private_key";

    private OutputStream stdin;
    private InputStream stdout;

    public void connect() throws Exception {
        var client = SshClient.setUpDefaultClient();
        client.start();

        var session = client.connect(USER, HOST, PORT).verify(5000).getSession();
        session.addPublicKeyIdentity(loadKey());
        session.auth().verify(5000);

        var channel = session.createShellChannel();

        var pipedOut = new PipedOutputStream();
        stdin = pipedOut;
        channel.setIn(new PipedInputStream(pipedOut));

        channel.open().verify(5000);
        stdout = channel.getInvertedOut();
    }

    public void sendMessage(String message) throws IOException {
        stdin.write((message + "\n").getBytes(StandardCharsets.UTF_8));
        stdin.flush();
    }

    public void readMessages() throws IOException {
        try (var reader = new BufferedReader(new InputStreamReader(stdout, StandardCharsets.UTF_8))) {
            String line;
            while ((line = reader.readLine()) != null) {
                System.out.println("Received message: " + line);
            }
        }
    }

    private KeyPair loadKey() {
        var provider = new FileKeyPairProvider(Paths.get(PRIVATE_KEY_PATH));
        var keys = provider.loadKeys(null);
        return keys.iterator().next();
    }
}

And for required dependencies

<dependency>
    <groupId>org.apache.sshd</groupId>
    <artifactId>sshd-core</artifactId>
    <version>2.11.0</version>
</dependency>