BTC-e API process

Question

I'm submitting a Sell trade via the API, and the orderid returned is 0. It appears the trade is successful, and the adjusted funds are returned by the response. So it looks like the trade is happening instantly.

I was originally worried about the orders taking a while and having to check to find out when an order is complete. I was planning on setting a timer to look at my tradehistory to look for a matching orderid for the trade that I submitted.

So three questions:

1) Are the orders always completed when the trade call is returned, so I can just skip having to check back on orders and

2) If it does return a non-zero OrderID does that mean the order isn't complete and I need to do the timed checking?

Finally, do these answers apply in the same way to a Buy order?

Thanks for the help. I understand the API well enough, but not how the underlying exchange functions.

Answer 1

I think I've been able to answer my own question. What I did was use the API to place an order that I knew wouldn't success by setting the price really low/high.

Because the order didn't process instantly it returned a non-zero OrderID to me.

Using the API I checked my order list and the order was shown there. So basically, if the order comes back with a non-zero OrderID it's still open for as long as the order still appears in the OrderList.

Answer 2

1) no, the order is not necessarily completely when your trade request is returned. Try posting a limit order that is very far out in the book. You guessed correctly... the order has only been completed immediately if it returns a zero. If it takes longer to be completed, it will be filled without ever returning 0, in which case you need to check your transactions or your active orders in order to know when it gets filled. One of these in combination with monitoring your balances should do the trick. So Jon Stevens is wrong btw because using your balance info in conjunction with your active orders makes it easy to tell for sure.

2) yes.

and yes it is the same for buys.

One thing to note is that assuming you want to implement similar checks on other exchanges, you have to be careful with the conventions of how balances are allocated between your open orders and your regular balance. For example, some exchanges like campbx differentiate between your liquid btc and your total btc, so you can easily see how much are tied up in orders. However, on btce you only have one metric, so when your btc suddenly drop you know this is because you have entered an order. And if you are using balances as flags for transactions you have to be careful not to mistake a cancelled sell order for a buy order, as both result in you btc suddenly jumping up. In order to make this disctintion it will help to monitor both the change in your btc and the change in your usd (or whatever currency you purchased it with) in conjuntion. Both changing at the same time means transaction, only one changing means either btc deposit or cancellation. You need even further flags to distinguish betweent the latter two.

In general I found that even if you don't think it's necessary, you should figure out a way of confirming every action you trigger or expect with exogeneous information from the APIs. Every different interaction with the api has a unique signature in the data (you just have to pinpoint it, sometimes with limited data on APIs like BTC-E), so the best practice is that after you trigger or expect any action, make sure that it is confirmed by some unique signature before you move on. It will make debugging much easier because it ensures that the state of your program really is what you think it is.

Hope that helps.