search

robinhood-unofficial / pyrh

Python Framework to make trades with the unofficial Robinhood API
https://pyrh.readthedocs.io/en/latest/
MIT License
1.79k stars 605 forks source link

Order Filled Price #293

Closed jkcaldwe closed 1 year ago

jkcaldwe commented 2 years ago

I am using the library to place limit buy and sell orders. Is there a way to confirm the order filled and at what price? The 'place_limit_buy_order' returns if the order was received but doesn't return the price it was filled at.

viaConBodhi commented 2 years ago

You should be able call ['details'] from the response which will expose {"average price :"} and {"quantity :"} which indicates if the price/quantity was immediately accepted. I'm using a modified version of this function so you may need to refactor this to get the raw response. You'll also need to consider capturing the "cancel_url" within the response to automate canceling if your algo requires filling

jkcaldwe commented 2 years ago

Thanks for the response. I am extracting the details of the response and it does include price and quantity. The issue is that I am using limit buy/sell orders and the response shows my limit but not the price it was actually filled at. For example, if the latest stock price is $10 and I want to buy, I may submit a limit buy order for $10.05. The response shows $10.05 as the price but when I look in Robinhood, the order is actually filled at $10.01.

I would like to have a way to determine what the order was actually filled at, not the limit price I submitted.

viaConBodhi commented 2 years ago

Have you tried to cross reference the orders endpoint by filtering on "limit" order then seeing if there is a unique id within the response that can be matched up in the orders "executions" or "ref_id"? If there is not a direct key match you could possibly, depending on your use case, use the "create_at" field via orders to help narrow your record scope based on the time you placed the order because the "updated_at" should only change when the record is adjusted per fills. From other use cases I've noticed their latency is pretty low and have needed to use "time" to help match record across views for other reporting.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.