Documentation for these APIs will be added to the wiki at some point but it’s not ready yet. When it finished, it’ll be added to this page: http://wiki.guildwars2.com/wiki/API:Main
I have been waiting for an update like this I have a feeling that it will be well used (by myself at least).
Thank you for your hard work with it from everyone who uses the API.
This is really great news, I have been waiting to see this live, just made a few tests looks really good.
one good thing would be before the documentation is ready if anyone of the API developers team can just post some of the parameters accepted by the commerce endpoint would be gold.
Would it be possible to get a URL that only has the buy/sell price/volume so we won’t cause massive traffic to the server if we don’t need the exact order book?
Would it be possible to get a URL that only has the buy/sell price/volume so we won’t cause massive traffic to the server if we don’t need the exact order book?
Could already exist, we won’t know the full list of valid params until they tell us in the documentation (or if someone is really good at guessing).
Has anyone actually worked on this? I’m not a programmer or someone who understands a majority of code (I’ve gone and learned a bit from Codecademy about 35% through JavaScript and attempted the first section of the YouTube API), but I was able to modify someone else’s gw2spidy script for my google sheet in order to generate the information I wanted. Is this going to work in the same way where it can work with google sheets, and if so, can I just substitute information (such as the website it pulls from) in order to make my current spreadsheet work?
Also, would someone tell me where I can get a list of which Item IDs correlate to which Items? I just want to quickly look up an Item and see it’s Item ID in order to plug that information into my spreadsheet when it becomes available for use.
Also, would someone tell me where I can get a list of which Item IDs correlate to which Items? I just want to quickly look up an Item and see it’s Item ID in order to plug that information into my spreadsheet when it becomes available for use.
live values (same values we can see in game) and not a delayed value like from GW2Spidy?
http://sirvincentiii.com ~ In the beginning…there was Tarnished Coast…
Full set of 5 unique skills for both dual-wield weapon sets: P/P and D/D – Make it happen
PvE – DD/CS/AC – If that didn’t work, roll a Reaper or Revenant.
I case these APIs work like the previous ones, these are most likely live values.
Thanks. I ran the value last night and match it with in-game value, they are the same.
This API is very helpful.
http://sirvincentiii.com ~ In the beginning…there was Tarnished Coast…
Full set of 5 unique skills for both dual-wield weapon sets: P/P and D/D – Make it happen
PvE – DD/CS/AC – If that didn’t work, roll a Reaper or Revenant.
I’m very thankful for the new API. Since the values are already cached, could it be possible to enable the all keyword for the prices API? That would be extra sprinkles on top.
Let the bards sing and the skaalds proclaim her glorious name forever[…]: Apatia!
I think you can get better performance if you run multiple queries (for 200 ids each) in parallel. The ids=all would take too long to complete for a client application to just sit there and wait for the data to return.
live values (same values we can see in game) and not a delayed value like from GW2Spidy?
They are live values (with 60 seconds of caching) for all APIs except the /v2/commerce/prices one, which is cached for about 5 minutes.
Can you reduce the cache time for prices? If the cache time for prices is so long then people will switch back to commerce/listings which probably puts more load on the server.
live values (same values we can see in game) and not a delayed value like from GW2Spidy?
They are live values (with 60 seconds of caching) for all APIs except the /v2/commerce/prices one, which is cached for about 5 minutes.
Can you reduce the cache time for prices? If the cache time for prices is so long then people will switch back to commerce/listings which probably puts more load on the server.
It seems that the commerce/prices adds the quantity and selects the current price on the server side, meaning processing time = server load — commerce/listing is seems to be posting values straight from the auction house listing without any added processing, thus much less server load.
You can always parse the values from commerce/listing on the client side to make it look like the values you get from commerce/prices.
http://sirvincentiii.com ~ In the beginning…there was Tarnished Coast…
Full set of 5 unique skills for both dual-wield weapon sets: P/P and D/D – Make it happen
PvE – DD/CS/AC – If that didn’t work, roll a Reaper or Revenant.
/v2/commerce/prices is what we show in search results on the TP and totally usable for places where absolutely up-to-the-minute data isn’t necessary.
/v2/commerce/listings is closer to being live data, but is also more expensive for us to retrieve. It may end up getting a longer cache time on it to avoid problems on the backend.
/v2/commerce/prices is what we show in search results on the TP and totally usable for places where absolutely up-to-the-minute data isn’t necessary.
/v2/commerce/listings is closer to being live data, but is also more expensive for us to retrieve. It may end up getting a longer cache time on it to avoid problems on the backend.
I have a TP website and we use commerce/prices to update all the items.
I realize that they can’t be live, but going from 1 minute to 5 minutes is a huge difference when prices can change very quickly.
If it is stuck at 5 minutes, then I would switch back to using commerce/listings which seems to put a heavier load on the server as it takes longer to complete.
/v2/commerce/prices is what we show in search results on the TP and totally usable for places where absolutely up-to-the-minute data isn’t necessary.
/v2/commerce/listings is closer to being live data, but is also more expensive for us to retrieve. It may end up getting a longer cache time on it to avoid problems on the backend.
I have a TP website and we use commerce/prices to update all the items.
I realize that they can’t be live, but going from 1 minute to 5 minutes is a huge difference when prices can change very quickly.
If it is stuck at 5 minutes, then I would switch back to using commerce/listings which seems to put a heavier load on the server as it takes longer to complete.
The cache times on those two APIs come from different places. /v2/commerce/listings I control, /v2/commerce/prices I do not.
That said, if /v2/commerce/listings starts stressing the commerce systems too much we’ll increase the cache time on the API frontends. Live data’s no good if folks are taking down the commerce servers to get it!
Try to use the right API for the data you need, basically.
Does the BL inside the game use either listings or prices? You just made me think that, if the results are cached, then the data we see in-game isn’t live? Or does it use other mechanism unavailable to the API to be live?
Does the BL inside the game use either listings or prices? You just made me think that, if the results are cached, then the data we see in-game isn’t live? Or does it use other mechanism unavailable to the API to be live?
/v2/commerce/prices is what we show in search results on the TP and totally usable for places where absolutely up-to-the-minute data isn’t necessary.
/v2/commerce/listings is closer to being live data, but is also more expensive for us to retrieve. It may end up getting a longer cache time on it to avoid problems on the backend.
Basically, if you search for ‘ore’, the prices you see on the list of results: mithril ore, iron ore, copper ore, etc. are the cached prices (prices). If you click on mithril ore, the individual prices you see such as “242 ordered at 30c, 500 ordered at 29c, …” are the non-cached prices (listings)
you may remember a bug a couple months ago where newest items showed a lot higher price than they were? like you would search for the item, it would say it sells for 20g, you’d click on it, and all the buy orders were for 30s. That was because the cache wasn’t being updated with the new prices.
Does the BL inside the game use either listings or prices? You just made me think that, if the results are cached, then the data we see in-game isn’t live? Or does it use other mechanism unavailable to the API to be live?
The TP uses the same backend APIs that both /v2/commerce/listings & /v2/commerce/prices uses. It doesn’t go through the public API layer though.
/v2/commerce/prices has a caching layer on the backend API, so the TP is getting identical values to the public API.
/v2/commerce/listings is cached on the Public API layer (currently for 1 minute) because the public API gets hammered much harder than the in-game TP. This is mostly due to folks spidering for the entire state of the market every few minutes, which no user would ever be able to do from within the game.
Pat, is it possible to provide a bulk prices page that only includes items that have changed their price in the last ~1-10minutes?
I was playing around with it a bit and settled on using: https://api.guildwars2.com/v2/commerce/prices?page=0&page_size=200
I first check if the buy and sell prices have changed before updating my numbers, and it seemed like more than 80% of the items’ prices don’t change very often (at least several minutes, I didn’t test it thoroughly).
It might be worth it to cache a list of items who’s price has changed in the last 60 seconds and offer that to people. by ‘worth it’, I mean they wouldn’t then need to get the price for every item all the time.
Does the BL inside the game use either listings or prices? You just made me think that, if the results are cached, then the data we see in-game isn’t live? Or does it use other mechanism unavailable to the API to be live?
The TP uses the same backend APIs that both /v2/commerce/listings & /v2/commerce/prices uses. It doesn’t go through the public API layer though.
/v2/commerce/prices has a caching layer on the backend API, so the TP is getting identical values to the public API.
/v2/commerce/listings is cached on the Public API layer (currently for 1 minute) because the public API gets hammered much harder than the in-game TP. This is mostly due to folks spidering for the entire state of the market every few minutes, which no user would ever be able to do from within the game.
I still don’t see why use /prices over /listings if /listing has the closest to accurate pricing. You can generally build your own prices on client side using /listings’ result plus /listings has more data than /prices — and probably the main reason why it’s getting hammered.
http://sirvincentiii.com ~ In the beginning…there was Tarnished Coast…
Full set of 5 unique skills for both dual-wield weapon sets: P/P and D/D – Make it happen
PvE – DD/CS/AC – If that didn’t work, roll a Reaper or Revenant.
/prices is more useful for viewing by humans. You have to consider that people have a reading speed of just a few bytes per second (at 1 byte per character for UTF-8 encoded text). So live data is no longer live data by the time they reach the bottom of the page.
/listings can return several pages of text.
/prices returns one line.
/listings takes longer and uses more resources, especially if all you’re after is the highest bid and lowest sell.
Most use-cases for the data in /prices don’t actually require the freshest data in the world. You can get it from /listings in that case if you do need data with a lower cache time, with the caveat that if it gets abused we’ll need to up the cache time on /listings until it isn’t much fresher than /prices.