I propose adding an order_id attribute to the TradeActivity entity returned by /v2/account/activities/FILL. This will allow associating fills with the corresponding order.
Description of problem: Users need a way to maintain a complete, accurate, and fault-tolerant local view of orders and fills. A basic part of this requirement is the need to know which fills correspond to which orders.
Current candidate APIs
To reliably track fills and associate them with orders, these are the candidate APIs and their current limitations:
/v2/orders/{order_id}: with an order ID, you can query the order status, which includes the shares filled and avg price. But, this provides only an aggregate view of the order's fills. If the order had multiple partial fills, this endpoint does not provide that granularity.
Streaming trade_updates: the websocket API provides a fully granular stream of fills, and provides the associated order entity. Great! But, a streaming connection can't be exclusively relied upon to maintain an accurate local view, since events will be missed if the connection goes down for whatever reason.
/v2/account/activities/FILL: The trade activities API provides a fully granular view of fills. And because historical fills can be queried, it is possible to backfill and maintain an accurate local view even if the connection is interrupted. But, there is no reliable way to link the fill activity to the associated order.
Adding order_id to the /v2/account/activities/FILL endpoint seems to me the right solution, but if there is another solution I'm missing, please point me in the right direction.
I propose adding an order_id attribute to the TradeActivity entity returned by
/v2/account/activities/FILL
. This will allow associating fills with the corresponding order.Description of problem: Users need a way to maintain a complete, accurate, and fault-tolerant local view of orders and fills. A basic part of this requirement is the need to know which fills correspond to which orders.
Current candidate APIs
To reliably track fills and associate them with orders, these are the candidate APIs and their current limitations:
/v2/orders/{order_id}
: with an order ID, you can query the order status, which includes the shares filled and avg price. But, this provides only an aggregate view of the order's fills. If the order had multiple partial fills, this endpoint does not provide that granularity.trade_updates
: the websocket API provides a fully granular stream of fills, and provides the associated order entity. Great! But, a streaming connection can't be exclusively relied upon to maintain an accurate local view, since events will be missed if the connection goes down for whatever reason./v2/account/activities/FILL
: The trade activities API provides a fully granular view of fills. And because historical fills can be queried, it is possible to backfill and maintain an accurate local view even if the connection is interrupted. But, there is no reliable way to link the fill activity to the associated order.Adding order_id to the
/v2/account/activities/FILL
endpoint seems to me the right solution, but if there is another solution I'm missing, please point me in the right direction.