Open Orders

Request the authenticated account's complete working-order snapshot through the encrypted REST protocol:

POST /api/v1/openOrders
Authorization: Bearer <access_token>

The body is a one-shot HPKE envelope whose logical request is get_open_orders. Use an official SDK:

JavaScript: GodarkRestClient.getOpenOrders()
Python: GodarkRestClient.get_open_orders()
Rust: GodarkRestClient::get_open_orders()
Go, Java, and C++: the corresponding idiomatic getOpenOrders / get_open_orders method

The decrypted OpenOrdersSnapshot contains:

rows: OpenOrderRow[]
server_timestamp: uint64
correlation_id: bytes
decimal_places: uint32
error_code?: uint32
reject_text?: string

Each OpenOrderRow includes:

Field	Description
`order_id`, `symbol_id`	Venue identifiers
`side`, `order_type`, `order_status`, `time_in_force`	Order enums
`price`, `quantity`, `filled_qty`, `remaining_qty`	Exact decimal strings
`leverage`	Applied leverage
`timestamp`	Placement timestamp
`correlation_id`	Original request correlation
`expiry_time`	Optional GTD expiry
`reduce_only`, `post_only`	Placement attributes
`take_profit`, `stop_loss`, `tpsl_status`	Optional TP/SL state
`close_reason`	Optional close classification
`peg_offset_bps`, `trigger_price`	Optional peg/stop instructions

Treat each snapshot as authoritative for the account's current working orders. For live lifecycle changes, subscribe to the encrypted Orders Channel. After reconnecting, replace local working-order state with a fresh snapshot before applying new updates.