Order IDs from market trades about api HOT 9 CLOSED

By the way, if you haven't noticed: each trade's "transaction ID" in the BIST /user_transactions/ response is actually the microsecond Unix timestamp at which the trade occurred. That'll give you better resolution than the verbose datetime stamps that Bitstamp specified in their protocol.

from api.

Since market orders effectively have zero lifetime, there is no need to assign them order IDs, as they could never be seen in a response to GetOrders, nor could they ever be canceled by CancelOrder. Due to the inherent race between deciding to execute a market order and actually executing one, we generally recommend that algorithmic clients issue limit orders instead, to protect themselves against unexpectedly unfavorable execution prices. If you do use market orders, then you can specify a tonce, which will be included in the OrdersMatched notices resulting from your order execution.

from api.

There is no facility to correlate historical market order trades with the PlaceOrder command that precipitated them, but no such facility is needed, as market orders always complete immediately, and the assumption is that the client will remain connected to the WebSocket long enough to collect the OrdersMatched notices resulting from the PlaceOrder command that executed the market order.

from api.

Thanks for the prompt response. My main concern is that all other exchanges we've developed for include this, so our software has been designed to later retrieve the history and check if there has been any price slippage. It just means creating a special case for Coinfloor. I'm assuming there no plans to include this in the future then?

from api.

What exactly do you mean by "price slippage"? If you are concerned that your orders might not execute at favorable prices, then you should be placing limit orders. And you should almost never have any need to query for your historical trades; you would only need to do this if you became disconnected while you had an order open and the order had a different quantity remaining when you reconnected, indicating that a trade had occurred against it while you were not connected. Since market orders can never be "open," this rare case would not apply to them.

As far as I am aware, there is no intention for Coinfloor to assign order IDs to market orders now or in the future.

from api.

Thanks again for the prompt response. From the above comment I believe you have understood what I meant, but I'll just clarify. By price slippage (cost perhaps makes more sense), I mean the difference between what I'm expecting to pay for X BTC, and what I actually pay. To elaborate with an example of my use case:

1. Orderbook updated via websocket
2. Calculate cost to buy 1BTC on current orderbook as $3000
3. Send Place market order message to buy 1BTC

In the case that someone else places the same order just before me, it is possible that 1BTC costs me $3001. I have noticed this happen on odd occasions on other exchanges.

In this case (and for my application), I still prefer to place a market order because ensuring the entire volume goes through on this trade holds a great deal of weight. Yes the downside is that their is the possibility of difference in cost, but for my application I am happy with this risk. Getting the full volume through is important. For later analysis / calculations, I simply want to check the executed price to account for any of these differences. I am happy though to just use the date time given in the user transactions response to match these up.

from api.

If getting the whole quantity traded is of the utmost importance to you, then couldn't you place a limit order at a price that is sufficiently deep into the order book that you're all but guaranteed a full and immediate execution? For example, if you have a need to sell 3 BTC exactly, then you can execute a market sell order for 3 BTC, but you could alternatively place a limit order to sell 3 BTC at a price of £1 to the same effect. Buying is not so clear cut; you would want to use the greatest price that your current available balance allows. For instance, if you need to buy exactly 3 BTC and you have £30,000 available in your account, then you can place a limit order to buy 3 BTC at a price of £10,000.

from api.

Agreed... placing the limit order as you mentioned is certainly an option. I followed that same line of thought you just outlined (buying being not as clear cut and having to use the greatest price my balance would allow). I think the matching on timestamp will be the simplest solution though.

BIST /user_transactions/ response is actually the microsecond Unix timestamp

No, hadn't actually noticed this. That resolution helps. Thanks for pointing this out.

from api.

Closed issue, because a solution was found. Thanks @whitslack

from api.