Meaning of Enums

Summary

There are lots of enums around the status of plays and other objects, and this document’s purpose is to define what each enum means for each object. This document explains the meaning of various enums related to the status of plays and other objects.

Wager Object

This object is returned from several endpoints, such as place_wager, place_multiple_wagers, get_wager_histories, and websocket events. It includes four fields of enum types: status, matching_status, winning_status, and update_status.

Status

• inactive: The play request has been received but is still in the validation process and cannot be matched or seen by any client yet.
• open: The play has passed validation and can be seen by clients and matched by other users.
• invalid: The play failed validation and never became available for any user to see. The most common reason is insufficient wallet balance during activation.
• canceled: The play was canceled by the client, and no amount was matched. If the play was partially matched, the unmatched portion is canceled. The play status will remain open, and matching_status will become fully_matched.
• void: The play was explicitly voided by the internal operations team due to regulatory requirements or other reasons.
• wiped: The play was automatically wiped when certain events occurred, such as all pre-match plays being wiped once a game transitions from pre-match to live.
• manually_settled: The play was not auto-settled due to data source issues or existing limitations, requiring human intervention to settle.
• settled: An auto-settled winning play will have this status. Once the wallet balance is updated, the status will transition to closed.
• closed: The final status for auto-settled plays. Auto-settled losing plays will go directly to closed.

Play Flow Examples

1. For a winning auto-settled play: inactive => open => settled => closed
2. For losing auto-settled plays: inactive => open => closed
3. For all manually settled plays: inactive => open => manually_settled

Matching Status

• unmatched: The play has not been matched with any other play yet.
• partially_matched: Only a partial amount of the play is matched with other play(s).
• fully_matched: The full amount of the play is matched with another play(s).

Winning Status

• lost: The play was lost, and no payout is made to the user’s account.
• won: The play was won, and the stake and profit are paid out to the user’s account.
• no_result: There was no official result for the game, so the stake is returned to the user’s account.
• tbd: The final result is still pending.
• manually_lost: The automatic process did not receive the final result, and manual intervention set the play to a loss.
• manually_won: The automatic process did not receive the final result, and manual intervention set the play to a win.
• draw: The play was a draw, and the original stake is returned to the user’s account.
• push: No side won, and the original stake is returned to the user’s account.

Update Type

• status: The play information has been changed.
• matching: A new matching bet for this play.

Market Object

This object is returned from the get_markets endpoint.

Type

• moneyline
• spread
• total

SportEvent Object

• sub_type: If null, it is a normal event. If “outrights”, it is a custom-created future/outright event.

Examples

There are many ways to use our API; here is one approach.

How to check what orders are currently on the exchanges orderbook

if status == 'open' and matching_status != 'fully_matched':
	print('I have', stake, 'on the exchange orderbook')
else:
	print('Order is not in exchange orderbook')

Case 1: fully cancelled case

T0: Wager, status='open', stake=$10 T0 + 1: canceled RESTful API call partner/mm/cancel_wager T0 + 2: receive websocket with wager, status='canceled'

T0: Wager, status='open', stake=$10 T0 + 1: canceled RESTful API call partner/mm/cancel_wager T0 + 2: is broken, how does SP handle it. T0 + 3: This is one way to do it, but each SP will approach it differently.

1. Call cancel_all_orders API to cancel all open orders.
2. Then call get_wager_histories for the last 10 minutes to get all the wager updates, just in case you do not have the exact time, or just call from the last disconnect time to now(), when the websocket got disconnected.
3. Once all orders are reconciled, connect to the websocket and repost orders.

Case 2: partially cancelled case

T0: Wager, status='open', stake=$10 T0 + 1: $3 gets matched, T0 + 1.1: canceled RESTful API call partner/mm/cancel_wager T0 + 2: receive websocket with wager, status='open', matching_status='fully_matched', stake=$3

Case_2-2:

T0: Wager, status='open', stake=$10 T0 + 1: $3 gets matched, T0 + 1.1: canceled RESTful API call partner/mm/cancel_wager T0 + 2: receive websocket with wager, status='open', matching_status='partially_matched', stake=$10, matched_stake=$3 (caused by what happened on T0 + 1 before ProphetX received the cancellation request) T0 + 3: receive websocket with wager, status='open', matching_status='fully_matched', stake=$3

Case 3: fully_matched

T0: Wager, status='open', stake=$10 T0 + 1: $10 gets matched, T0 + 1.1: canceled RESTful API call partner/mm/cancel_wager T0 + 2: receive websocket with wager, status='open', matching_status='fully_matched', stake=$10