This Confluence space describes the technologies available for customers wishing to integrate and consume our Sports Data Services products. It explains both the V3 Integration Service contract and describes what is required to receive messages, how those messages should be interpreted and where to get further help or advice.

What are the steps taken for an integration to succeed?

In order for a new customer to begin offering live bookmaking services, a series of steps must be completed and sub-tasks must be finalized. The following work-flow serves as an example of these steps:

1. Establishment of contacts and review of integration documentation provided by our Business Development or Integrations team. Our documentation is comprehensive and contains all the necessary information for successful on-boarding of the customer. It is readily available for access in Confluence, the page currently being reviewed.

2. After reviewing the documentation, the customer will provide an end point for the integration service deployment. We will verify connectivity and proceed with the deployment if there are no issues.

3. Upon completion of the setup, the customer will receive access credentials for both their licensed services and the support tools in use. Our Integrations team will provide assistance with integration support via email, Skype, and telephone for critical matters. If the customer has also acquired Smartstream services, our Integrations team will manage the initial setup phase of this part of the Genius Sports' portfolio and then continue as a liaison.

4. As the customer's team begins work on receiving and processing information posted by Genius Sports, our Integrations team will provide running assistance in support of integration. For InPlay services, we recommend completing a load test before launching. For PreMatch, the throughput of your trading platform is less significant. Additionally, before launching InPlay and PreMatch services, templates will be created and set up in cooperation between our Trading teams and the customer.

5. The Go-live moment will occur when your Production service is in place and your platform correctly receives and processes all messages being sent for the products you have licensed with Genius. The Production launch will take place during the agreed-upon time window. Once live, the customer is expected to receive, process and utilize content from Genius without technical fault, making the content available to customers.

6. Following the immediate launch, our Integrations team will provide initial post-release support by monitoring the performance and stability of the customer. Once the transition is completed, day-to-day management will be handed off to our Support team, who will become the point of contact for the customer for all service-related issues. Please note that if you continue integrating other sports or products with Genius after the initial go-live window, then you're obliged to inform the Customer Integrations team when you're ready to launch with the additional content, so that the support services on our end could be set up for them as well.

What is needed to deploy the service?

An end point capable of receiving and responding to HTTP POST messages originating from the following IP addresses, which have to be whitelisted on your side:

54.72.77.116

34.242.67.155

34.242.6.161

34.241.220.64

52.19.163.53

52.213.172.249

52.214.86.245

99.80.74.200

54.76.226.75

34.240.244.24

34.252.158.247

54.77.177.22

Genius Sports does not need to whitelist any incoming connections from your side.

What can I expect to receive?

For Prematch Manager: Updategrams for events, markets and results. Events and markets will be updated until the Kick-Off time, customer will then remove those markets from being avaialble, and resulting information will follow from Genius Sports once the conditions for a result to be produced have been met.

For Inplay Manager: Updategrams for events, markets and results. Events with coverage will receive continuous updates from Kick-Off until completion. Depending on your service level, also Match and Trading State are provided.

How do we know that match has been finished?

Once an event concludes, you'll see the following:

1. Any open markets will be immediately resulted or, depending when the results are confirmed (which may take only a few seconds if the scores aren't in question, to some minutes), closed and then resulted. This is done through Optima Evenue, OpenBet Feed Handler or your client application.
2. For Inplay events, the fixture's Match State will move to a post-match state. This will be signaled by an update on the match state contract. The post-match state description can vary between Inplay sports, with all possible values available for your development team's review here: Understanding Match State

Where can I find details of the match state feed for the Inplay sports? How will I receive the information?

The workings of the match state feed are explained in Understanding Match State section. 

How will I receive the information?

After an event has been created, any modifications to the event properties, market creation, market price updates, and favorable conditions for resulting will trigger the posting of an Updategram. Each message will contain information specific to a single event. In the case of market updates, Inplay and Prematch market updates will always be separated into their own Updategrams.

What are Updategrams?

Fixture, MarketSet and ResultSet are mandatory messages for the Prematch service. Inplay also includes additional MatchSummary and MatchDetails Updategrams. Optional message types include Coverage and SportProperties.

1. Fixture contains the fixture details to allow your trading platform to create and update events successfully. You can expect to receive as few as one Fixture message per event, with a possible follow-up update sent in case of Kick-Off changes and so forth.
2. MarketSet create the markets for an event and update those markets if prices for the selections within that market change or the market state itself is updated. Each update to a market will trigger a new MarketSet to be posted to your service end point. Simultaneous updates for a single event will be pooled into one inclusive UpdateGram.
3. ResultSet will result all markets that were created for an event. Depending on the sport and your service that you take from Genius Sports, you will receive a ResultSet either after the event has finished or several ResultSets during gameplay, when winning outcomes for markets have become known. Each ResultSet will provide the resulting data for only one market.
4. MatchSummary, MatchDetails and MultiSportMatchState are message types that carry the Inplay Manager's Match State information. Summary is a quick snapshot of the current situation on the pitch whilst Details, as the name suggests, provides a detailed overview of the event and its history. MSMS carries a limited amount of event information if no in-depth data is available to produce full match state content.
5. Coverage messages are posted after a fixture has been booked on the Inplay Manager service or created through the Prematch Manager after reaching the lead-in time. Included in the Coverage message is the Match and Trading State feed availability information as well as the confirmation that your event booking went through. If either Match or Trading State coverage status changes after the initial creation, a new Coverage command is sent.
6. SportProperties (as an optional element in the Fixture message) will provide detailed information for Inplay Tennis, Basketball and Football events down to factors such as the court surface type for Tennis and how many sets will be played to determine the winner.

What is an event or a fixture?

An event aka fixture is a shell into which markets will be created. When a fixture is booked on the Inplay Manager or set up to create on the Prematch Manager, you will receive a Fixture message containing the parameters of the event when the creation conditions have been met. These details include the event name, the event ID, competitor information, competition information, region information and finally, the event state. An event has two states: Scheduled and Deleted. Scheduled indicates that the event is going to go ahead and start at the specified Kick-Off time whilst Deleted indicates that the event has been either cancelled or altered to such a degree that all markets are to be pushed or voided, thereby returning all bets. Whilst the event itself is identical between Prematch and Inplay services, the markets for these events by default are stand-alone. An optional feature, not compatible with all trading platforms, will allow Prematch markets to transition into Inplay markets when the event phase changes from Prematch to Inplay.

What is a market?

A market, identified by the market name, its ID and its market type ID, is a shell for selections that are traded through the market. We will provide you with a spreadsheet listing all our market types with full details available for all sports and services during the integration, available here. A market has several statuses that it goes through during its lifecycle. Please note that PreMatch markets should no longer be offered once the start time of the event is reached (the ExpiryUTC value, attached to each market) and that Genius will not close the Prematch markets, instead the customer's trading platform is responsible for removing those markets from being available at the designated KO/ExpiryUTC.

What are market statuses?

1. Open - market is open for betting.
2. Suspended - market has been temporarily removed from being available.
3. Closed - market has been closed and is not expected, though can be, opened again.
4. Resulted - market has reached the conclusion of its lifecycle and is resulted. Resulted markets cannot transition back to an earlier lifecycle phase.

Market is only meant to be available for betting during the Open status. Other states can include pricing for selections, however market-level status will always override the selection prices and availability. You should no longer offer a market once we have sent the respective ResultSet message.

What are selections?

Markets contain several selections that are entries on which bets can be placed. Selection count and type depends on the market type itself. Details for each market type and its selections are available on the included documentation.

Will all selections for a market be sent through at market creation?

Yes and no. Some market types include dynamic selection creation, therefore your trading platform and integration implementation must support later insertion of selections into an existing market. As an example, the Inplay Manager Football's Correct Score market will dynamically create new selections as the match progresses and goals are scored. Additionally, according to your requirements, we can update either all selections in a market if there has been a price change for at least one selection within said market or we can only send through the update for the lone selection in question.

What are selection states?

1. Unpriced – the selection has not yet been priced.
2. Trading – the selection is priced and can be offered for betting if the market status is Open.
3. Suspended – the selection has been removed from being available.

What is the availability hierarchy?

Availability of pricing follows the following order: event > market > selection. Please note that selections can be suspended even for a market that is set to trade on an event level when, for instance, the odds of one of the selections has become 1.00 or N/O. That selection is then suspended and the cut-off point for that suspension is fully configurable by your trading team through settings that apply to that market. However, if a market is suspended or closed, and has active selections, then based on the availability hierarchy those selections cannot be offered to customers, as the market's status is always more important than the selection statuses within that market.

What is a result?

ResultSet Updategrams contain the information that will allow you to settle each market on a selection level. Type of the market will determine how many winning and losing selections there are as well as whether the market might be void altogether. A market can be updated to a Resulted status straight from having been in state Open and closure of the market beforehand is not mandatory.

What are selection resulting values?

1. None - no resulting information has been yet sent for the selection/market, but is expected to be sent the future when the event has concluded or when the resulting information has been made available.
2. Winner - the winning selection of the market.
3. Pushed - the selection in question was voided, meaning that the bets on it should be returned. As an example, if a player doesn't take part in a match but was priced up for the Goalscorer markets, their selection will be voided since they did not participate.
4. Loser - as the name applies, all bets placed on this selection have lost.
5. Placed - a winning selection in a multiple winner market. An example would be the Prematch Golf's 'Place Top 10' and other similar markets. Every losing selection is a Loser, however all golfers that were in the Top 10 for the event in question, are resulted as Placed. Depending on the sport and market, there can be more than the expected amount of selections sent through as Placed since several players can Place for the same position.
6. Partial – this type of resulting covers markets such as Asian Handicap and includes additional resulting data to properly result such markets for which the straight outcome win/lose does not apply and percentages come into play instead.

The element <AdditionalResultData> is used convey the data for markets where Placed and Partial resulting values is used.

1. The Place - field will contain the number of selections designated by the market type, e.g. Top 10 usually contains 10 selections. It is of course possible to go over that limit if players tie and you should then apply the dead heat rule on your side for pay-out management.
2. The CountInPlace - field will inform you if there is more than one person on a specific spot. If two people came in as number 3, therefore sharing the podium, then the Place element will be 3 for both (since both players finished on the third place) and the CountInPlace element will be 2 (informing that two players share the spot).
3. For Partial results, the following percentages can apply and a bet can be resulted with lesser combined percentage than 100%, if one half of the bet wins and the other half loses.
   1. If both bets win, the PercentageWin will be 100%
   2. If both bets lose, the market is resulted as lost outright
   3. If half of the bet is correct, then Win will be 50%.
   4. If half of the bet is voided, Void will be 50%

How are Handicap Values Applied?

If the market has -1 then it means that the Home Team selection has +1 and the Away Team selection has -1. If the market has 1 then it means that the Home Team has -1 and the Away Team has +1.
For sports for which the Home Team and Away Team designations are not useful (for example Tennis or Snooker) handicaps should be applied in the same way but with Player 1 substituted for the Home Team and Player 2 substituted for the Away Team.

Once integration is complete, how soon can we launch?

Once your development project is complete and you are happy that everything is working as you expect, we will deploy the integration service to our production environment, configure the systems, create user accounts and complete various other pieces of administration in order to make the system work. You should aim to give us at least 1-2 weeks' notice in order that we have time to schedule and deliver the work.

Can I request new features or changes to system behaviour?

Yes, please contact the Integrations team with any requests you might have. The process to deliver the change is as follows:

1. We will draft a description of the requested change using SpecFlow and ask you to confirm that we have correctly interpreted your requirements,
2. Once the requirements have been agreed, we will estimate the work required and obtain commercial approval (if required),
3. The work then enters the development backlog for delivery as soon as possible,
4. Completed work requests will be delivered to the UAT environment for test and approval. Load tests may also be conducted.
5. Once approved, changes will be pushed to production during the next release window.

What time zones are used in Updategram Messages?

All times will be in UTC.

Can I have fixture start times sent in my local time zone?

No. We will send all times in UTC and you must modify the start time shown to your users. This allows you to support customers in multiple regions or time zones.

In which languages will updates be supplied?

All updates will be supplied only in English using the entity's official name. Where an entity's description is not normally written in English, for example because it represents a competition or team from a region where English is not the first language, the formal name of the entity will be used. Entity names will include characters from across the UTF8 character set to allow accurate representation of the data.
Examples:

• Olympique Lyonnais, Coupe de France
• Manchester City, Capital One Cup

Where an entity would normally be described using non-Latin characters, for example a Greek football team, we will supply an English rendering of the name that as closely as possible matches the official name. Where possible the official English version of the entity, as determined by the entity itself or the competition organisers, will be used.

How should I handle entities named only in English?

Customers typically transform entity names (teams, competitions, players etc.) to match their preferences or to fulfil regulatory requirements. Typically this is done by building a translation table that maps our entity IDs (which are immutable) to a preferred text.
For example, Manchester United football team has competitor ID 10105. If a customer wishes to present this team as Man Utd they would create a table that associates our ID with their preferred text. The preferred text would then be used whenever competitor 10105 was presented to customers.The translation however must be performed on the customers end - no translations can be performed within the Integration Service, all team and player names will be sent in English.

What data will be supplied for translation?

During the integration project we will supply an Excel spread sheet listing all competitions, teams, players and market types used by the services that are to be supplied by the customer. This information will include entity IDs to allow a translation table to be built.
Customers would then build a system to identify and handle new entities so that new translations could be added to the table as they are required. As above, the translations must be performed on the customers end.