So — the long answer is that the backend component that implements the trading post’s matching engine doesn’t store enough data for you to implement this 100%. You can get most of the way there, but some stuff might slip through the cracks.
Some initial notes:
- For every order that you create (buy or sell) a single record is made in /v2/commerce/transactions/current/{buys,sells}. It’s assigned a unique id and a creation date.
- Every time someone else’s order matches with yours, a record is made in /v2/commerce/transactions/history/{buys,sells}. The id of the historical record does not match the id of the your matching order.
- When someone else’s order matches yours (but does not fully consume it), your current order’s quantity is adjusted. This leaves your original order available to be matched by future orders.
- The “created” date between current/history will match up.
- When an order is cancelled, it’s purged from current without leaving a record in history.
An example walkthrough, assuming only two people are interacting with a trading post that starts out empty:
- You make a buy order for 250 Mithril Ore for 5c/unit. You’ll now have a record in /v2/commerce/transactions/current/buys that looks like:
{ “id” : 1, “created” : “timestamp1”, “item_id” : 19700, “quantity” : 250, “unit_price” : 5 }
You haven’t sold anything yet, so your history will be empty.
- If you then list a sell order for mithril at 50c/unit (because buy low sell high), your current/buys will be unchanged but you’ll have a record in current/sells:
{ “id” : 2, “created” : “timestamp2”, “item_id” : 19700, “quantity” : 99, “unit_price” : 50 }
- Then if someone comes along and purchases 1 of your mithril ore @ 50c, the current/sells entry will be amended to reflect the updated quantity, and you’ll have a record in history/sells noting that there was a purchase:
current/sells:
{ “id” : 2, “created” : “timestamp2”, “item_id” : 19700, “quantity” : 98, “unit_price” : 50 }
history/sells:
{ “id” : 3, “created” : “timestamp2”, “purchased” : “timestamp3”, “item_id” : 19700, “quantity” : 1, “unit_price” : 50 }
It should be noted here that the “created” timestamp is the same between the current order and historical order — but not necessarily unique. It should be enough to correlate between the two using item_id/unit_price, noting that you may have multiple listings for the same item_id/unit_price (which can safely be aggregated on your end). You’re going to lose track of some paid exchange fees one way or another.
- If someone makes another purchase of your sale listing, a new history/sell record is made:
current/sells
{ “id” : 2, “created” : “timestamp2”, “item_id” : 19700, “quantity” : 93, “unit_price” : 50 }
history/sells:
{ “id” : 3, “created” : “timestamp2”, “purchased” : “timestamp3”, “item_id” : 19700, “quantity” : 1, “unit_price” : 50 }
{ “id” : 4, “created” : “timestamp2”, “purchased” : “timestamp4”, “item_id” : 19700, “quantity” : 5, “unit_price” : 50 }
The entry in current/sells will be removed once either (A) you cancel the order, or (B) the quantity reaches zero. Determining which happened requires you to store the old version of current/sells locally, notice that the record no longer exists, then search history/sells for matching transaction that would matches it. More tersely, you basically have to reconcile the current transactions with the historical logs on your end.
Anyway, I realize this is kind of a ramble and probably doesn’t help much, but it’s a rough overview of what the API is exposing and how you can get actual data out of it. You’ll have to ask a more specific question if you want a more specific answer, I’m afraid.
