Hi,
I’d like to request an improvement to the New Order Futures API endpoint (/fapi/v1/order) by having the “realizedPnl” included in the response.
The “realizedPnl” for an order is currently only available via the Account Trade List (/fapi/v1/userTrades) endpoint. I’m requesting this data to be returned in the response of the New Order request when the newOrderRespType is set to RESULT.
Why?
I want to maintain my wallet balance based on the orders that I place. Without the realizedPnl field it is only possible by querying it using the Account Trade List endpoint.
Example 1:
Current wallet balance: $20
Enter short position for: $10. (cummulative quote quantity, “cumQuote”)
Our current usable wallet balance would be $10 after the trade.
The price changes.
We exit the short position for $9 (“cumQuote”). Our profit from the trade is $1.
Our expected wallet balance after the trade is $21. This equals to $10 from our leftover funds + $9 from the cummulative quote quantity of the 2nd trade + $2 that is twice the PNL = $21.
However, as we don’t have the PNL in the response of the 2nd order, we can’t reconstruct the correct wallet balance unless we query the PNL from the Account Trade List endpoint.
Example 2:
Current wallet balance: $20
Enter short position for: $10. (cummulative quote quantity, “cumQuote”)
Our current usable wallet balance would be $10 after the trade.
The price changes.
We exit the short position for $11 (“cumQuote”). Our profit from the trade is -$1.
Our expected wallet balance after the trade is $19. This equals to $10 from our leftover funds + $11 from the cummulative quote quantity of the 2nd trade + -$2 that is twice the PNL = $19.
Similarly as in Example 1, we can’t correctly track the wallet balance without the realized PNL information.
This issue can be worked around by querying the Account Trade List endpoint after receiving the New Order response. Another workaround is using the websocket Order Update event “rp” field, but I haven’t tried that.
I think this problem shouldn’t require making additional requests, or subscribing to websocket updates. These both add latency and extra complexity to a trading system and with this improvement it could be solved much more elegantly.
I hope you consider this suggestion.