FAQ
The most frequently asked questions on how opentote works
FAQ Opentote
-
The various bet types can be found in bet types document on the “docs” page. For access to our “docs page please contact support@i-neda.com if you would like to set up a connection.
-
OpenTote is a multi-currency system and provides currency conversion functionality to allow you to bet in currencies other than the tote’s pool currency. Your merchant specific currency exchange rates can be managed directly via the API.
However, totes only accept bets in monetary amounts to two decimal places. As a consequence rounding must be done before sending converting stakes and costs to the tote. This rounding can sometimes result in currency breakage. If you or your customer has specific requirements for how that breakage is managed it may be a better option for you to perform that currency conversion in your own system.
-
A list of the track codes can be found on the “docs” page. For access to our “docs page please contact support@i-neda.com if you would like to set up a connection.
-
Connections are secured using HTTPS with full SSL end-to-end encryption of the API and merchants’ endpoints are IP whitelisted. A VPN can be setup for merchants who require traffic to be secured in that way.
-
The push API WSDL files that you should implement and host as part of your push endpoint service can be accessed on request.
A pull API WSDL is provided for reference can be accessed on request.
Please contact support@i-neda.com for access.
-
The OpenTote test environment runs a set of racecards each weekday, test cards are available from 10am UK time and are settled by the test totes in the afternoon or evening. The racecards available on the OpenTote test system are connected to tote test environments to ensure that the test system mirrors the production system as closely as possible.
“Groundhog” racecards are run on this environment with the same horses competing in the same races each day with the same winners and scratches. This makes it easy for you to plan out your test scenarios in advance.
To get access to the test environment please contact our support team to request a discovery pack. On completion of the provided test connection form our support team will be able to create a test merchant for you and provide credentials and connection details for you to use.
-
If you would like assistance in recreating any specific scenario that isn’t represented in the test schedule then please contact our support team who will be happy to assist with setting up something for you. Please provide advanced warning for any special requests, as we may need to seek assistance from one of the test totes (depending on the nature of the scenario).
-
There are some differences in the level of test provision provided by the different totes connected to the OpenTote test environment.
- The UK tote reconciles a selection of its racecards every day. The Ascot and Bath racecards are always reconciled each day.
- Irish and US test racecards will only reconcile if a certain volume of bets have been placed into the pools on that card. If there is a requirement to reconcile a specific Irish card on the test system please let us know and we can arrange with the Irish tote.
- Phumelela requires that reconciliation be requested in advance for its South African test racecards. Please provide as much advance notice as possible when requesting this and we will arrange It with the tote.
-
Each OpenTote customer is allocated a single merchant account for their traffic. In cases where a customer is a third party technical provider for several other companies one merchant can be assigned per group or region.
-
Each merchant is typically configured with a single active push feed endpoint with one or two failback addresses that could be switched to by request at times when they are required.
We do not actively rate limit racecard requests on the pull API, however we prefer merchants with large quantities of shops or terminals to cache racecard data at a central location rather than to make direct racecard requests from each POS.
We do not ourselves enforce any concurrency limits for wagering, however, we can advise on recommended concurrency levels based on any limitations of the specific tote systems you will be interfacing with.
-
An optional “community” field is available on each request type. When you populate this field with a unique retailer identifier it allows the i-Neda support team to perform reporting and searches on a retailer-by-retailer basis as required.
-
When a new racecard is made available by OpenTote a NewCardReady update will be sent to your endpoint by the push API. At this point you can make a racecard request for that card to fetch its details and store them in your racecard database.
As the racing offered by OpenTote is international, there is no explicit start or end of day process or time when the system is offline. The system runs 24 hours a day and cards are made available when they are provided by the host totes. For UK and Irish racing this tends to be between 8am and 9am UK time each day.
-
When a pool has been settled you will receive a PoolStatusUpdate message from the push API notifying you that the pool is “paying complete”. At this point you can begin to cash tickets in that pool using the CashTicketRequest to collect winnings and refunds information for each ticket.
If you are interested in a specific ticket, the TicketEnquiryRequest will return all details of a ticket, including its settlement status and any winnings or refunds due.
-
Yes, it is important to process updates synchronously and in the order in which they were received otherwise your racecards could end up being inconsistent. If you wish to add concurrency to your push message processing then having a separate thread dedicated to processing odds updates may improve performance (although the odds updates themselves should be processed in order if you wish to keep your race data consistent).
-
OpenTote will consider a push message to have failed to deliver if it does not receive a successful response within five seconds. When a message cannot be delivered the push service continues to attempt to resend that same update until it is successfully acknowledged.
Odds messages are an exception to this, because of the transient nature of odds messages, delivery is only attempted once for each odds message.
-
In this situation we would recommend having a manual procedure to allow you to make a full racecard request for all cards and process the response. Racecard responses from the pull API will always contain a fully up to date version of each racecard including odds, results, et cetera.
-
A number of pool types span across multiple races, as a consequence pools are associated to races via legs (in other words pools have a many-to-many relationship with races via legs). The details of the legs for each pool are contained in the “leg” elements of a pool, included in the leg element is the race number for that leg and its “sequence” (or ordering position).
Here is an example of the leg elements for a six-leg, six-race UK Tote PlacePot pool that runs from race 1 to race 6:
-
Will-pays are provided by some totes at after the penultimate leg of a multi-race bet has run. They contain the current probable payouts for the remaining units left active in the pool. They are not final payouts.
Contact Us
i-neda, The Hub, Farnborough Business Park, Farnborough, Hampshire. GU14 7JP. 01252 701010