Guides
  1. Trading API

Meaning of Enums

Understand ProphetX enum values for orders, markets, and events with API enum values.

Summary

Use this page to understand the meaning of enum values returned for orders, markets, and events.

Order Object

This object is returned from several endpoints, such as place_order, place_multiple_order, get_order_histories, and WebSocket events. It includes four enum fields: status, matching_status, profit_status, and update_status.

Status

  • inactive: The order request has been received but is still being validated. It is not yet visible to clients and cannot be filled.
  • open: The order has passed validation, is visible to clients, and is available to be filled by other users.
  • invalid: The order failed validation and never became available to users. The most common reason is insufficient wallet balance during activation.
  • canceled: The order was canceled by the client, and no amount was filled. If the order was partially filled, the resting portion is canceled. The status remains open, and matching_status becomes fully_matched once only the filled portion remains.
  • void: The order was explicitly voided by the internal operations team due to regulatory requirements or other reasons.
  • wiped: The order was automatically wiped when certain events occurred, such as all pre-match orders being wiped once an event transitions from pre-match to live.
  • manually_settled: The order was not auto-settled due to data source issues or existing limitations, so it required manual settlement.
  • settled: An auto-settled profitable order has this status. Once the cash balance is updated, the status transitions to closed.
  • closed: The final status for auto-settled orders. Auto-settled losing orders move directly to closed.

Order Flow Examples

  1. For a profitable auto-settled order: inactive => open => settled => closed
  2. For a losing auto-settled order: inactive => open => closed
  3. For a manually settled order: inactive => open => manually_settled

Fill Status

  • open (unmatched): No part of the order has been filled yet, and the order is still resting.
  • partially_filled (partially_matched): Part of the order has been filled, and the remaining amount is still resting.
  • filled (fully_matched): The full order amount has been filled.

Profit Status

  • loss (lost): The order closed at a loss, and no payout is made to the user’s account.
  • profit: The order closed at a profit, and the cost and profit are paid out to the user’s cash balance.
  • no_result: There was no official result for the event, so the original cost is returned to the user’s cash balance.
  • tbd: The final result is still pending.
  • manual loss (manually_lost): The automatic process did not receive the final result, and manual intervention set the order to a loss.
  • manual profit (manually_profit): The automatic process did not receive the final result, and manual intervention set the order to a profit.
  • draw: The order was a draw, and the original cost is returned to the user’s cash balance.
  • push: No side profited, and the original cost is returned to the user’s cash balance.

Update Type

  • status: The order information has changed.
  • matching: A new fill or matching update was received for this order.

Market Object

This object is returned from the get_markets endpoint.

Type

  • moneyline
  • spread
  • total

Event Object

  • sub_type: If null, it is a normal event. If “outrights”, it is a custom-created future/outright event. The current API model name is SportEvent.

Examples

Use the following examples to interpret common order status combinations.

Check whether an order is currently on the exchange order book

if status == 'open' and matching_status != 'fully_matched':
	print('I have', quantity, 'resting on the exchange order book')
else:
	print('Order is not on the exchange order book')

Case 1: Fully canceled order

T0: Order, status='open', cost=$10 T0 + 1: Send REST API call partner/mm/cancel_order T0 + 2: Receive WebSocket update with order, status='canceled'

T0: Order, status='open', cost=$10 T0 + 1: Send REST API call partner/mm/cancel_order T0 + 2: WebSocket update is missed because the connection is interrupted T0 + 3: Reconcile state after reconnecting

One approach is:

  1. Call cancel_all_orders API to cancel all open orders.
  2. Call get_order_histories for the last 10 minutes to retrieve all order updates, or query from the last disconnect time to now() if you know exactly when the WebSocket disconnected.
  3. After all orders are reconciled, reconnect to the WebSocket and repost any required orders.

Case 2: Partially canceled order

T0: Order, status='open', cost=$10 T0 + 1: $3 gets filled T0 + 1.1: Send REST API call partner/mm/cancel_order T0 + 2: Receive WebSocket update with order, status='open', matching_status='fully_matched', cost=$3

Case 2.2: Partial fill before cancel completes

T0: Order, status='open', cost=$10 T0 + 1: $3 gets filled T0 + 1.1: Send REST API call partner/mm/cancel_order T0 + 2: Receive WebSocket update with order, status='open', matching_status='partially_matched', cost=$10, filled_quantity=$3 (current API field filled_quantity; this reflects the fill that occurred before ProphetX received the cancellation request) T0 + 3: Receive WebSocket update with order, status='open', matching_status='fully_matched', cost=$3

Case 3: Fully filled order

T0: Order, status='open', cost=$10 T0 + 1: $10 gets filled T0 + 1.1: Send REST API call partner/mm/cancel_order T0 + 2: Receive WebSocket update with order, status='open', matching_status='fully_matched', cost=$10

Updated 9 days ago