<p>In my experience requesting the full market depth from MtGox, often results in flat out incorrect information. To deal with this I've resorted to constructing my own, in a similar manner as you described above. </p>

<p>What I do is, using the <a href="https://en.bitcoin.it/wiki/MtGox/API/Streaming" rel="nofollow noreferrer">websocket api</a>, I look at all incoming <code>depth</code> events. I then keep two ordered arrays of bids and asks. On depth events if the volume is positive I add the order to the respective array based on the <code>type_str</code> property. If the <a href="https://bitcoin.stackexchange.com/questions/11512/negative-volumes-returned-from-mtgox-websocket-api-request/11513#11513">volume is negative</a> I remove the object from the array.</p>

<p>Make sure to combine objects of the same price, but with different volume. Likewise when removing objects if the negative volume is less then the volume of the same prices object then only deduct from the volume instead of removing. This is how it is done on MtGox's server and it will lead to errors if done differently. </p>

<p>After letting this run for a little while, though not deep, the order book is quite accurate and representative of what the MtGox order book should be.</p>

CC BY-SA 3.0
2013-06-11T18:27:53.420Z
Hi! I also tried to manage my own order book and have noticed that after having it run for a while, it accumulates entries that should have long been removed. But, I have so far only used the "depth" events' "total volume" field. Does the information included in the "trade" events actually not show up as "depth" events? Also, have you found the incremental volume information (positive vs. negative) to be more accurate than using the "total volume" field? Thanks!
Markus A.
CC BY-SA 3.0
2013-06-11T19:14:49.997Z
so I resized that all trade events will have a corresponding depth event with negative volume. So just using depth events you can construct an order book by adding all depth objects with positive volume and removing objects with negative volume. To make sure they are the same I match the `price_int` and `amount_int` fields before removing the object. I dont use `total volume` at all, and have found this to work quite well.
Loourr
CC BY-SA 3.0
2013-06-11T19:56:02.390Z
Hmmm... I also used price_int to match the entries... let me try using amount_int instead of total volume to see if that's more reliable... Have you ever noticed any depth events arriving "out of order", i.e. you receive an event with a "now" timestamp that is earlier than the timestamp of a previously received event?
Markus A.
CC BY-SA 3.0
2013-06-11T20:16:20.063Z
No, but I'll be keeping an eye out for it in the future. Also be sure you take the absolute value of the negative volumes before you compare them with existing orders.
Loourr
CC BY-SA 3.0
2013-06-09T19:52:07.753Z
2013-06-15T02:24:22.657Z
2017-04-13T12:47:33.743Z
Loourr
<p>I'm trying to write a program using the Mt.Gox API to keep an up-to-date consistent view of their market depth. My current approach is as follows:</p>

<ul>
<li>Connect WebSocket and subscribe to depth updates</li>
<li>Wait for 1 minute, collecting updates</li>
<li>Request full market depth data via <a href="http://data.mtgox.com/api/1/BTCUSD/depth/full" rel="nofollow">http://data.mtgox.com/api/1/BTCUSD/depth/full</a></li>
<li>Merge the collected updates into the market data by time-stamp (more recent wins)</li>
<li>Continue merging all future updates into data</li>
</ul>

<p>After playing around with this for a while, I noticed that the full depth data download doesn't always match the data generated from updates. That's why I added the 1min delay, thinking that maybe the Mt.Gox server only updates the full depth data periodically, but doesn't generate it on the fly.</p>

<p>But even with this protocol, if I run the program twice in parallel, I end up seeing different data in both instances.</p>

<p>Any idea what I might be doing wrong?</p>

<mtgox><api><market-depth>
Keeping consistent market depth using Mt.Gox API
Markus A.
# Keeping consistent market depth using Mt.Gox API

(Asked by: username_0 on 2013-05-31)

I'm trying to write a program using the Mt.Gox API to keep an up-to-date consistent view of their market depth. My current approach is as follows:

* Connect WebSocket and subscribe to depth updates
* Wait for 1 minute, collecting updates
* Request full market depth data via <http://data.mtgox.com/api/1/BTCUSD/depth/full>
* Merge the collected updates into the market data by time-stamp (more recent wins)
* Continue merging all future updates into data

After playing around with this for a while, I noticed that the full depth data download doesn't always match the data generated from updates. That's why I added the 1min delay, thinking that maybe the Mt.Gox server only updates the full depth data periodically, but doesn't generate it on the fly.

But even with this protocol, if I run the program twice in parallel, I end up seeing different data in both instances.

Any idea what I might be doing wrong?

**Tags:** mtgox, api, market-depth


---

## 1 answers

### Answer by username_1 on 2013-06-09. Score: 4

In my experience requesting the full market depth from MtGox, often results in flat out incorrect information. To deal with this I've resorted to constructing my own, in a similar manner as you described above.

What I do is, using the [websocket api](https://en.bitcoin.it/wiki/MtGox/API/Streaming), I look at all incoming `depth` events. I then keep two ordered arrays of bids and asks. On depth events if the volume is positive I add the order to the respective array based on the `type_str` property. If the [volume is negative](https://bitcoin.stackexchange.com/questions/11512/negative-volumes-returned-from-mtgox-websocket-api-request/11513#11513) I remove the object from the array.

Make sure to combine objects of the same price, but with different volume. Likewise when removing objects if the negative volume is less then the volume of the same prices object then only deduct from the volume instead of removing. This is how it is done on MtGox's server and it will lead to errors if done differently.

After letting this run for a little while, though not deep, the order book is quite accurate and representative of what the MtGox order book should be.

> **Comments:**
> **username_0**: Hi! I also tried to manage my own order book and have noticed that after having it run for a while, it accumulates entries that should have long been removed. But, I have so far only used the "depth" events' "total volume" field. Does the information included in the "trade" events actually not show up as "depth" events? Also, have you found the incremental volume information (positive vs. negative) to be more accurate than using the "total volume" field? Thanks!  
> **username_1**: so I resized that all trade events will have a corresponding depth event with negative volume. So just using depth events you can construct an order book by adding all depth objects with positive volume and removing objects with negative volume. To make sure they are the same I match the `price_int` and `amount_int` fields before removing the object. I dont use `total volume` at all, and have found this to work quite well.  
> **username_0**: Hmmm... I also used price_int to match the entries... let me try using amount_int instead of total volume to see if that's more reliable... Have you ever noticed any depth events arriving "out of order", i.e. you receive an event with a "now" timestamp that is earlier than the timestamp of a previously received event?  
> **username_1**: No, but I'll be keeping an eye out for it in the future. Also be sure you take the absolute value of the negative volumes before you compare them with existing orders.  

---

