Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
SportCast recommends using PUSH messaging, to determine fixture status and availability.
Clients should open up a secure https URL endpoint that SportCast can push JSON messages to. These messages include information about whether a fixture is live and open for betting or not, as well as a series of additional informational fields that will assist with fixture mapping.
In the Fixture Update message, SportCast can provide several 'out-of-the-box' solutions for fixture mapping purposes. Industry-standard fixture IDs can be added, to allow for quick and easy pairing on the client side. These include:
BetGenius ID
BetRadar ID
BetFair ID
SportCast can also open up a custom API endpoint for clients to map their own IDs, which can then be sent back to the client in all subsequent messaging.
Fixture Update messages are sent every time the MatchState of a fixture is changed. This allows clients to quickly add or remove a fixture from betting:
"MatchState": 1, = Disabled
"MatchState": 2, = Enabled
An example Fixture Update message is seen below:
This section describes the steps required and options for integration of the BetBuilder Widget UI.
Main Component of the Workflow
Bookmaker Web Page
Operator web site that hosts the BetBuilder Widget.
BetBuilder Widget
The BetBuilder Widget UI which is present via an iFrame and hosted on Sportcast servers.
Bookmaker BetSlip
Customer controlled BetSlip that will display the market/bet created by the BetBuilder Widget and allow the end user to set stake and place the bet.
BetBuilder Engine
BetBuilder Pricing Engine and API which is the main Sportcast hosted server-side component.
Bookmaker Back-end
This represents that bookmaker platform or back-end where markets are created, and bets are processed.
Messaging and Communication Between Components
1. Widget load and initialization
BetBuilder Widget initialization and load is controlled via URL parameters:
· Key: Operator access key.
· FixtureId or ConsumerFixtureId: If the FixtureId property is specified then the Sportcast fixtureId is used to load that appropriate fixture. Alternatively, an operator can map their own fixtureId, called the ConsumerFixtureId.
· Culture: Controls the language translation that is applied. Example “es-ES” for Spanish.
· Brand: An operator can have different style sheets which are loaded based on the Brand parameter.
· Region: An operator can specify different regions which allows BetBuilder to display different market sets.
Example: https://betbuildergbgen2-uat.sportcastlive.com/?key=xxx&fixtureid=107675&brand=xxx®ion=xxx
2. BetSlip saved
Once a user has built a bet using the BetBuilder Widget and confirmed it by pressing the “Add to BetSlip” button, a message containing the slip details is sent to the BetBuilder Engine. This step requires no operator configuration.
3. Bet Response message: Bet details passed to bookmaker back-end
Typically, the customer provides a secured HTTPS end point where the BetBuilder Engine pushes a response to the bet placement. Example JSON:
The properties of this message are:
· BetSlipUid: Unique identifier of the BetSlip send in the Bet Response message.
· MarketId: Bookmaker platform Id of the market created. (Optional)
· HttpCode: Code of any error to occur. (Optional)
· ErrorMessage: Description of any error. (Optional)
· Identifier: The unique identifier hash string of the BetSlip from the Bet Response message.
· ConsumerFIxtureId: The fixtureId of the BetSlip.
· TimeStamp: DateTime the message was sent.
· BetBuilderData: Details of the bet selections made and price values that are returned.
End Point: https://clusteruat.sportcastlive.com/public/betfeedback
4A. Bookmaker BetSlip population (Optional)
The bookmaker platform/back-end will typically persist the market and bet that is received in point 3. At this time, one possible workflow is for the bookmaker platform to pass this information onto the bookmaker BetSlip. (This task can also be performed using client-side messaging).
4B. Bet Feedback message: Bookmaker passes bet receipt back to BetBuilder
The bookmaker platform must inform the BetBuilder Engine that the Bet Response message has been received and processed. Without this step, the bettor will receive an error message saying their betslip could not be saved. The fields that are passed back here can be customised to meet bookmaker requirements. Example JSON:
4C. Bet Confirmation message: Bookmaker passes bet placement details back to BetBuilder
After a customer places a bet in the bookmaker system, the bookmaker platform can send details of this confirmed bet back to the BetBuilder Engine. This can help the Sportcast trading team assist with risk management. Example JSON:
Endpoint: https://clusteruat.sportcastlive.com/public/betconfirmation
5. BetBuilder Engine passes the BetBuilder Widget the Bet Feedback message received in point 4B
This allows the BetBuilder Widget to react to a bet successfully progressing to the bookmaker BetSlip. The information in the Bet Feedback message can be bubbled up to the bookmaker website.
6. BetBuilder Widget bubbles up message to host website (Optional)
The BetBuilder widget bubbles up a message through the bookmakers hosting iFrame after having received the Bet Feedback confirmation relayed via the BetBuilder Engine. Typically, this message presents the same fields that are returned from the bookmaker platform in 4B. This option presents a client-side mechanism for updating the bookmaker BetSlip. Example JSON:
Our award-winning UI is fully customisable for operators and gives end-users the ability to build accumulators made up of related selections within a single event.
Trillions of combinations are possible across thousands of selections within hundreds of different market types. BetBuilder is an established industry leader and has been used to create millions of bets, worldwide.
https://canonical-origin-betuilder-host-uat.sportcastlive.com/
This example site shows an end-to-end example of the Widget UI embedded in a bookmaker page. The blue section at the top represents the Bookmaker web site and bet slip. The white section is the Widget UI siting within its iFrame.
See the site.js file for an example of a listener that bubbles up the feedback message described in point 6) of the UI Workflow
Once the BetBuilder bet exists on the operator BetSlip, the BetSlip is outside of the scope of BetBuilder. In order to ensure that a price is still valid when a customer places the bet, the following options are available:
· Set a timeout period for the bet to be accepted.
· The operator can query the BetBuilder Engine requesting the current price for a BetSlip. This is done by passing back the GlobalIds that are delivered in the original Bet Response message using the RequestBetPriceById API
The BetBuilder UI accept various parameters as part of the URL:
API Key
API Key The API key unique to a client's profile.
“&key=”
Fixture ID
Sportcast's own Fixture ID. These are always unique, and never change.
“&FixtureId=”
Consumer Fixture ID
This can be a custom ID that allows you to map fixtures. For example, we support BetGenius and BetFair ids.
“&ConsumerFixtureId=”
Odds Format
These must be provided as part of a pricing ladder in order to function:
“&odds”= AmericanPrice DecimalPrice FractionalPrice HongKongPrice IndoPrice MalayPrice
Theme:
The BetBuilder UI can be customised to suit your styling needs.
“&brand=” yourbranddark yourbrandlight
Language
Any language is supported using ISO culture codes. Translations must be provided.
“&culture=” e.g. en-GB, es-ES, ru-RU etc.
Swap Home/Away team positioning for US sports: This applies to American Football, Basketball, Baseball and Ice Hockey
“&pos=rev”
Region
This parameter is used for restricting certain markets from the offering
®ion= Germany France
Embedding native apps
This parameter is used for embedding the UI into an mobile application
&native=android
&native=ios
This section describes the options available for bespoke styling of the BetBuilder UI.
The BetBuilder UI can be customised to tailor its appearance for as many different brands as necessary. Themes can be light or dark and each component of the UI can be customised. Custom styling can be applied for mobile, desktop and tablet devices. Clients can request multiple brands
BetBuilder has been designed and built with a customisable approach to allow the application of your brand and ensure a seamless and consistent experience for your end users. This guide covers the customisable components, styles and information necessary to effectively apply your brand to the Bet builder interface.
Colours
Colour is an integral part of branding. It conveys the mood and the tone of your brand. To use colour appropriately it is important that you establish a colour palette and colour hierarchy for Bet Builder. Brand colours should be mapped across the below palettes, showing their technical characteristics (Hex and RGB).
What you need to do (Checklist):
· Use brand approved colours for the below palettes. (Note: gradients can be replaced with solid fills by providing the colour specs and vice versa)
· Make sure that your use of colour follows the correct hierarchy and usability principles.
· Make sure that your colour palette complies with the accessibility principles.
Fills
This palette is used to fill components – either their foreground or background.
States
This palette is used for the various states of some selectable / interactive elements.
Text
The text palette consists of a main text colour and a text colour when the text is on a coloured background to ensure enough colour contrast for legibility.
Backgrounds
This palette is used to fill large background areas in the UI.
Shadow elevation
Shadows are used to depict elevation of elements to give extra focus to the user.
Corner radius
Default UI uses rounded corners to soften the look and feel of the interface. A consistent px radius value is used throughout.
Colour usage in UI
Accessibility
Colour should not be used as the sole method of conveying content or distinguishing visual elements. We need to consider making our colour choices accessible to all users. A colour contrast analyser could be used to check the contrast ratio between foreground and background colour. Ensure that any text and background colour combination you use is of sufficient contrast to meet AA colour contrast requirements.
Colourable is a useful and simple to use online tool that lets you test different text/background colour combinations in order to determine AA (or better) standards compliance.
Contrast
Your colour palettes should ensure sufficient colour contrast between elements so that all users can see the different elements easily. Use a tool such as Adobe Kuler: Colour wheel | Colour schemes to create colour palettes that will provide complementary colour options with a suitable contrast for your chosen brand colours.
Legibility
Text that appears on coloured backgrounds should be legible and meet accessibility standards. Both backgrounds and text must use colours and opacities that, when used together, meet these standards. Consider for colour blind users the text might appear unclear or blurry to them. Always be sure that you are using high contrast colours.
Typeface
Typography is key to making your content easy to read and understand. We use one font to keep the experience as uncluttered and default as possible for the user, and the style guide can be simply edited. Our default application font is Lato.
What you need to do (Checklist):
· Ensure you use a brand-specific font.
· Make sure that your font uses appropriate sizing to follow readability and legibility best practices.
Typography usage in UI
Accessibility
Accessibility is a critical part of digital experiences that should not be overlooked. Here are a few things to consider:
· Contrast: Make sure there is enough contrast in your content to direct the reader’s attention to the important messages and enhance the visual appearance.
· Colour: All colour combinations should pass the WCAG Level A.
Allow operators to customise how they present prices to the customer.
Pricing ladders can be applied to all types of integration. Operators can control every step of the ladder to ensure the prices displayed snap to specific levels.
Odds Formats Sportcast support a variety of odds formats:
In order to apply laddered pricing, operators provide Sportcast with a set of custom ladder values, and these are applied via JSON.
JSON - Sample Pricing Ladder Snippet:
Proforma Our ladder proforma, detailing all required input to build a custom ladder, can be sent upon request.
Results are sent for each unique market created
Once a game is complete and settled a Results message will be pushed from the BetBuilder Engine to the operator.
Example JSON:
A result is sent for each unique market that was created for the fixture. The Markets key in the Identifier property from the Bet Response message in section 3 of the workflow.
Each market has an overall result and each leg within the market also has a result.
Valid results for a market/leg are:
C#
It is necessary to maintain a Mapping Dictionary if there is no shared identifier already known to both Sportcast and the integrator. This dictionary is maintained by the integrator following this basic workflow:
Step 1: Entity Listing Sportcast provides the integrator with a list of entities for anything that needs to be mapped. This list can include: leagues, teams, fixtures and players. The entity list can be provided in Excel or a custom end point can be established where the entity list can be dynamically fetched. The message format can be customized but is typically just the entity name, sometimes an abbreviation/nickname and the Sportcast Id.
Step 2: Mapping
When a new fixture for a supported league enters the Sportcast system we push a message to a client endpoint with the details. This is the generic message format:
Multiple fixtures can be sent in one message. This message is the same response format as the GetFixtureList API which can be queried for disaster recovery, testing/development and service start-up.
The integrator maps the Sportcast entity to their own internal entity and maintains this dictionary for the lifecycle of the integration. Once a mapping is created it is preferred that the integrator share the mapping information with Sportcast. Typically this is done by posting a simple message containing both the SportcastId and the integrator's mapped Id to a custom HTTPS end point.
A typical mapping message would be as follows, with the ConsumerFixtureId being the client identifier and FixtureId being the Sportcast identifier:
Using this information, Sportcast adds the mapping to the Sportcast database so that mappings are now maintained by both parties.
Step 3: Exposing the Mapped Ids Once Sportcast has knowledge of the mapped entity Ids, we will provide these Ids in all appropriate messages and APIs used by the integrator.
Format
Sample Output
American
+475
Decimal
5.75
Fractional
19/4
HongKong
4.75
Indo
4.75
Malay
-0.211
A pre-built user interface that is embedded on the client site via an iFrame.
The advantage of this approach is that the operator is not required to conduct any UI development, as the widget delivers a fully functional and responsive interface ‘out of the box’. The Sportcast widget supports mobile, desktop, tablet, and terminal interfaces.
The interface can be customised to include operator branding, colours, fonts, spacing and graphic icons. Market placement/grouping/availability can also be customised further.
Sportcast allows operators to deep-link directly to the widget to load a specific fixture from the operator’s fixture page.
Through accessing elements of our API framework, operators are provided the flexibility to generate flags within their existing interface beside BetBuilder-enabled fixtures, or to create their own BetBuilder fixture menu.
Widget Integration Workflow
A widget integration facilitates bet creation within the operator’s sportsbook, such that BetBuilder bets can be handled in keeping with other sportsbook bets by the end user.
After a punter creates a BetBuilder bet through the UI and selects ‘Add to BetSlip’, the bet details are passed through to the operator back-end system. Where the bet is a new selection/combination, this market is created within the system (either as a market or a selection depending on the system in question). From here, the operator’s systems will return a message to the BetBuilder widget with the identifier of the newly created selection. This message is subsequently passed on from the widget to the operator’s BetSlip for the stake to be entered and the bet to be placed.
All markets are settled via the back end, and settlement messaging can be provided at a per-leg level for display purposes on the customer account/bet screens.
BetBuilder supports every major language and is used by operators worldwide.
Translations can be applied in UI and API integrations (they do not apply to Market Matching).
Every element can be translated, into any major language.
Culture Codes
Sportcast support ISO Culture Codes. The parameter used in the API is a combination of an ISO 639 two-letter lowercase culture code associated with a language and an ISO 3166 two-letter uppercase subculture code associated with a country or region. For example:
· en-GB - English, Great Britain
· en-US - English, United States of America
Operators provide a set of custom translated values, and these are applied via JSON.
JSON- Sample Translation Bundle Snippet
Proformas
Our translations proformas, detailing all required translations for a given sport, can be sent upon request. For an example, see the football proforma below:
Translation proforma: