Direct Link: IDs and Field Names Cheat Sheet

The core fields you'll work with on the Trading API, plus the handful of IDs you'll actually need to carry around.

Vocabulary

Field	Meaning
`order`	One submitted order
`price`	American price (`-110`, `+150`). Always an integer on the price ladder.
`quantity`	Risk amount in USD (min $1). Not contracts.
`strike`	The number on a spread/total (`-3.5`, `48.5`); absent/`null` on moneyline
`strike_id`	Identifier of one selection at one strike — what you submit an order against
`filled_quantity`	Filled amount (cumulative on REST, per-fill on WebSocket — see Order lifecycle)
`open_quantity`	Still resting on the book
`fill_price`	Price a specific fill executed at
`order_strategy`	`fillOrKill` or `ALO`; omit for a plain limit order
`trade` / `trade_execution`	A fill

The IDs

ID	Who creates it	Shape	Where it appears	Notes
`order_id`	ProphetX, at submit	`partner_<uuid>`	`submit_order` response, `get_order`, `get_order_history`, matched detail rows (`order_id`), WebSocket `orders` (`id`)	Your stable key for an order. Pass as `{id}` to `get_order`.
`external_id`	You, before submit	≤100 chars, letters/digits/`-`/`_`	Echoed on every order read and WebSocket message	Must be unique per order; a reused one is rejected (that's your idempotency guard). Suggested: `{aggregator_id}_{uuid}`.
`aggregator_id`	You (self-declared)	same format rule	Order reads (`get_order`, history); not on WebSocket messages	Attribution key — keep it identical on every order (e.g. `juicereel`). Tell ProphetX the value you chose.
`strike_id`	ProphetX	32-hex string	Fixtures (`get_multiple_markets`, `get_strikes`), order book WebSocket, every order object	What you submit against. Changes when the strike changes — refresh from fixtures/WebSocket, don't cache for long.
`sport_event_id`, `market_id`, `outcome_id`	ProphetX	integers	Fixtures and every order object	Needed if you call parlay or market-level endpoints.
`user_id`	ProphetX	UUID	Order objects	The linked user's ProphetX account id. Also the WebSocket private channel suffix.
`matching_id` / matched-detail `id`	ProphetX	integer	Matched detail rows, WebSocket fill messages	Identifies one fill, not the order.

Resolving a `strike_id` to its market and outcome

Some endpoints (notably parlay quoting) want sport_event_id + market_id + outcome_id rather than a strike_id. You don't have to reverse-engineer it: GET /v4/mm/get_strikes returns strike_id → event_id, market_id, type, sub_type, and the selection objects inside get_multiple_markets carry strike_id, outcome_id, price, and quantity together. Store all four when you ingest fixtures and you'll never need to look one up at order time.

Price rules in one place

price must be an integer and on the ladder from GET /v4/mm/get_price_ladder; anything else is 400 invalid_price. Values in (-100, +100) don't exist.
For an order you send, price is a limit (the worst you'll accept), not a target. Fills happen at the resting orders' prices, best first, never worse than your limit.
price on an order you read back is still your limit. Fill prices are per-fill (fill_price on WebSocket, price on matched-detail rows).

Vocabulary

The IDs

Resolving a strike_id to its market and outcome

Price rules in one place

Resolving a `strike_id` to its market and outcome