Guild Wars 2

The character data returned from the API is up to ~5 minutes old, so returning HP isn’t really useful. It could technically return the other stats, but computing all that is a bit difficult so it doesn’t currently.

Items with chosen stats are a known issue. There’s currently no way to tell that an item has chose-able stats, nor can you determine via API which stats are currently selected. It’ll get fixed at some point, but probably not within the next month :<

Kyle Corver.1897:

Hey,
for sure I am using the options to get multiple items with ids=… . I figured out, that there is a maximum of 100 IDs, that are possible? So when trying to query n items I still have send n/100 queries to the API.

There’s a maximum of 200 ids/request, you may be hitting IIS’s URL length limit. You can also use the ?page_size=200&page=X parameters to paginate through the resources if you’re hitting the URL length limit.

Kyle Corver.1897:

Can I find any information about the refreshing rate of the api? Prices at the TP change very fast – so it isn’t even possible to get the real-time-prices?

All endpoints currently have a 5-minute cache. The cache is necessary to decouple the API from game services so that an API catastrophe does not cascade to other services.

If you’re only interested in the current price (and not every listing available) I highly recommend using /v2/commerce/prices instead (as it has a much lighter footprint on our backend).

IIRC I looked into exposing it at one point and couldn’t make sense of the data. This is something that a few people have requested, so I might take a few more stabs at it in the future (approaching it from the viewpoint of the story journal is a good idea — I hadn’t thought of that).

That’s an issue on our side; we had some connectivity errors this morning which caused some things to temporarily break. Lemmie know if you’re still having issues and I’ll check it out.

There was an outage this morning from ~5-7 AM PST, might have been related. Looking into some other possibly related issues with the /v2/guild endpoints now.

xanthic.9478:

If the item_id on the recipe page is “invalid” anyways(as in it is superseded by output_upgrade_id) and won’t be added to the items endpoint, it would be nice if it was removed outright (from that recipe) or the items endpoint gave a useful error message.

I’m of the opinion that the endpoint shouldn’t dump out bogus values; I’ve made a github issue and will probably remove it at some point. My original concern was that removing it would break existing applications, but in hindsight, leaving it in breaks existing applications in a more subtle and more confusing manner.

:(

Khisanth.2948:

Just ran into these as well. They exist in my transaction history but items wasn’t returning anything.

Huh, weird, must have made a mistake when I was going through the whitelist at some point.

Went ahead and whitelisted all items in /v2/commerce/prices that weren’t already in /v2/items.

Providing the breakdown is the about the same amount of work as providing the % completed, unfortunately. It might be a bit easier with some shortcuts (e.g., only looking at individual map completions), but I haven’t really looked at that data before so I can’t really make a good estimate.

There’s an existing issue on github for this feature; I’ll probably get around to it at some point but it’s not currently high on my priority list.

AllIsVain.6409:

PPK is here and the EU kills API changes numbers every 30 seconds, is this intended?

Your question isn’t very specific, so I’m guessing you mean “should it not be updated realtime”?

The PPK data (and deaths, for that matter) are sent periodically from the game servers via a best-effort transport to any other servers interested in the data (one of them being an API backend server). Since it’s best-effort, some data might get dropped or delayed (not sure how frequently this happens). Because of this, there’s going to be some reporting latency. Due to our network architecture, it’s not something that can be worked around.

EDIT: Well, it looks like there’s a bug or two with the PPK numbers. tracking issue.

Maybe next month? I haven’t had time to look at it yet, been busy with all the other endpoints :<

Items/skins have some weird behavior — the icon is only used iff the item has no default skin. If there’s a default skin, the skin’s icon is displayed instead.

For some reason, the gathering skins contain somewhat invalid data that at some point in the past crashed backend servers (I think I might have fixed that?) so I blacklisted them from the API. There’s actually a really old issue about this; I should look into that some more and see if I can get it fixed.

Sorry about that :<

xanthic.9478:

What is the intended behaviour here? Should I be able to find item ids that don’t exist in the items endpoint that map to an item that actually exists and would have that id if it was in the items endpoint?

I mostly didn’t want to break existing applications by making output_item_id conditional.

Whenever output_upgrade_id is present, output_item_id is not used. There are some placeholder items that are relics of times gone by (for the interested, they’re like “Immediate” type items which are consumed before entering your inventory), but it was probably a mistake including them.

The output_upgrade_id references /v2/guild/upgrades.

Gilj.6304:

Is there any news about having external access to game chat?

It’s still something I really want to do, but haven’t yet been able to commit time to.

The main crux is just budgeting out a solid month for a feature when there’s a bunch of lower-hanging features and bugs. When I get around to implementing it, pretty much everything else is gonna come to a standstill for awhile, so I want to find a good place for a long pause.

Seems to work for me; in general the server will kick back a HTTP 502 response after about a minute or so. If you don’t get a response at all forever, there’s something weird going on.

The way you’ve phrased it — “making connections to the server until it times out” — makes me think there’s a routing issue somewhere on the internet that’s blocking connectivity between you and our datacenter.

Sariel V.7024:

Do you know how recently that was changed?

I believe the SSL cipher suite was changed for the Dallas datacenter on Jan 22nd; I think the old cipher suite is still in use in the Frankfurt datacenter temporarily (but might be wrong about that).

I’m able to successfully request from the Frankfurt datacenter, but I’m seeing errors in the logs, so something’s afoot. Looking into it some more.

EDIT: Looks to have been caused by some internal service restarts; not sure why it took so long to come back up though.

Turns out there was a mis-configuration in the Frankfurt data center! Got the relevant parties involved and they’re going to have it fixed at some point. Thanks for the report, sorry about that! (this only affects guildwars.com and isn’t related to the OP).

The downtime history is an interesting idea; might be beneficial to set that up.

Everything looks up from here though, and there hasn’t been a deploy in ~20 hours. Usually when there’s a hotfix parts (most) of the API goes down as the backend servers patch and restart, but since there hasn’t been one recently I’m not sure why you’d be seeing this now.

I’m not sure how/why the missing recipes aren’t appearing. By my reading, they should have been put in the whitelist queue if they’ve been used (and I have a hard time believing they haven’t been used). Made a new github issue for this and I’m going to spend some time today rooting around in the log files to try to figure out what’s going on.

AFAIK the config change was made at the load balancer level, so it should affect all ArenaNet sites, including guildwars.com.

If you’re having TLS handshake errors, I highly suggest updating (or changing) your browser and seeing if that fixes the issue.

sookya.8625:

I think that the division/points of a player will not be added in /pvp/stats with this update? (or i missread/overseen some posts at github PR, I’m not that familiar with the PullRequest-Feature on Github sorry.)

That’s correct, the current division/pips of a player will not be added to /v2/pvp/stats until later (the backend support for that won’t land until the next game release). I’m hoping to get the rating_type and /v2/pvp/seasons endpoint out sometime next week.

I think we changed our TLS configuration to not use deprecated cipher suites. The certificate is unchanged, but we no longer support RC4 ciphers or MD5/SHA1 digests. That might be the issue, but I’ve no idea why that’d be a validatorexception and not something like “no suitable cipher suite” or just “handshake failure”.

Here’s the proposed endpoint changes for the rating_type (ladder type? not sure what the optimal name is) and some other misc. stuff. Will probably turn it on next week, let me know if you’ve got any feedback before then!

sookya.8625:

do you have any ETA for the ladder type? Would be super awesome to realize some ideas I have in my mind..

Hmm, looks like ladder type is actually available from the backend I’m talking to. I’ll look into exposing that early next month (as well as some other things). Can’t make any guarentees on per-game pip changes, though exposing the current season standings is on the todo list.

Nabrok.9023:

The same could be accomplished with a “successful_yaks” field. For towers/keeps/castles this would be the number that arrived, and for camps it would be the number that reached their destination.

IIRC it’s stored as a number representing how much supply has been committed towards the upgrade (e.g., by workers carrying supply around) — I think the only difference is that yaks arriving now is what’s contributing the supply. It’s been awhile since I looked through that, so it might have changed since, but might as well expose that if we’re exposing current upgrades, I think.

Malediktus.9250:

A few more appeared, so it looks like it is updating slowly.

So funny story.

I forgot to actually update the configuration to populate the whitelist queue when it detects missing achievements. Working on pushing some config updates, sorry for the hassle :<

Tiscan.8345:

IDK if these have already been reported, but a lot of the “Explorer”-Achievements return wrong (? or unexpected) data. Orr for example: https://api.guildwars2.com/v2/achievements?ids=103&lang=en

There are multiple entries in the “bits”-structure with an empty text. As far as I have seen, those do not show up in game in the achivements-tab – only in the API (5 for Orr, 9 for Ascalon, 1 for Kryta and 3 for Maguuma).

And if you take a look at https://api.guildwars2.com/v2/achievements?ids=100&lang=en you’ll see that “Dredgehaunt Cliffs: Tribulation Caverns” and “Timberline Falls: The Foundation Stones” show up twice (as do “Bloodtide Coast: Moriarity’s Hold” and “Gendarran Fields: Brigantine Isles” in the “Krytan Explorer”). This seems to be a more serious bug as those dupes show up inside the game if you look at the achivements (I have 100% map-completion and while both Tribulation Cavers show up as already discovered, only one of the Brigantine Isles entries shows up as discovered)

This is possibly just a case of content being weird — the API dumps out the data as it is. It’s a bit annoying that the API exposes achievement bits that are culled in the in-game UI, but they’re technically still there — since they’re cross-referenced by index in /v2/account/achievements removing them would be tricky (and potentially break things).

It’s important to note that for a lot of achievements you don’t need to complete all bits to be awarded the achievement — for example, Shiverpeak Explorer only requires 175 of 177 bits to be completed. The number of bits required for completion is available in the “tiers” field of /v2/achievements and/or in the “max” field of /v2/account/achievements. Thus, even though some bits are unused, you can still be awarded the achievement.

It’s definitely kind of weird, but my current opinion is that it isn’t broken, per say. I’ll poke someone about the Brigantine Isles dupe bit though — that seems like a bug.

Just whitelisted the new festival achievements. It’s gonna take a bit of time for everything to make it through, but it’ll get there. Any achievements returned from /v2/account/achievements are getting put in the queue (or … should be) so we should get through all of ’em pretty quick.

I don’t recall if you can see the upgrade status of enemy objectives in-game, but if you can’t I’ll need to talk to people before I can commit to exposing them via API. I’ve got an existing github issue for this feature.

Just deployed the support for this today.

Just deployed it! It needed some backend support that just landed with this release

Ah yeah, I think someone mentioned this in gitter and I promptly forgot. Made a tracking issue.

cisco.9510:

Found another bug: The minis, that have the unlock string property, are not translated into the languages you are requesting. For names its working.

Whoops. That’ll be fixed the next time I do a deploy (probably mid-late next week).

Yep, it’s on the list of things to do. Thanks for the pull request!

sookya.8625:

I already did such a request (except the “exact pip number”) about a month ago :p

https://forum-en.gw2archive.eu/forum/community/api/Request-for-pvp-games-and-pvp-stats

Ah fair. I’ve been trying to move “the list” out of my head and into a proper system (i.e., github issues) so that stuff doesn’t get lost. Apparently some stuff got lost :<

bostrees.5306:

The image returned for Unidentified Dye https://api.guildwars2.com/v2/items/20323 is a 256×256 image, as opposed to the more standard 64×64 for nearly every item I’ve pulled information on.

Yep, that’s just how content works. The game resizes it internally.

:/

That’d be pretty cool. I made a tracking issue for it (kinda surprised there wasn’t already one).

Created a handful of tracking issues:

• Glider skins.
• Outfit skins.
• Finisher skins.
• Mail carrier skins.

Seems reasonable; I created a tracking issue on github for this.

saphir.8564:

Hi,
one of my Trading Post transactions (its id: 1489725948) has item_id 69595; however https://api.guildwars2.com/v2/items/69595 says that there is not item with such id.
The same situation with: 69023 (transaction: 3355254320); 69445 (transaction: 3355006952) and 69430 (transaction: 3353027601).

Those items all have no name and the “under construction” working sign icon, so they were likely blacklisted from the API. It does look like they’re acquirable (via the jungle pvp reward track) so I’ll poke someone about that.

Thanks for the heads up.

EDIT: Turns out the issue was just on my end; went ahead and whitelisted those items. They should show up in the API at some point.

Seems reasonable. Created a tracking issue on Github.

The quip rifle was a weapon wielded by Scarlet during one of the LW1 events (I think Queen’s Jubilee?). I shouldn’t have made it to the API, but that was before we put a manual whitelist step in front of stuff. It’s kept in for compatibility purposes (??) but I’m thinking of going through and re-blacklisting a lot of broken stuff in there at some point.

Yeah, this patch just added backend support for whitelisting achievements. I need to go through and bless all the ones that should be exposed — I’ll take care of that later this week.

The 2015 Wintersday achievements were likely marked as “hidden” in this release so they don’t appear unless they’re unlocked. They’ll reappear once they’re manually whitelisted.

Teddiebear.1573:

This leaves the two branches with quite high coupling. Are there any upgrades like that or any plans to add this?

So, I just tossed together an upgrade tree visualization thing with vis.js: warning may crash browser (source). Probably want to open it with Chrome because Firefox is choking on it a bit for me.

The per-vendor trees basically start at each of the “Restoration 1” upgrades; from the visualization it doesn’t seem like there’s any coupling at all between the trees. They’re all currently self-contained, though it’s technologically possible for a new upgrade to have cross-tree prerequisites. I don’t work on the game so I have no idea what our future plans are, this is just idle speculation.

Anyway, I’m not very knowledgeable about the upgrade tree; you’re better off having a gander at the data yourself.

Teddiebear.1573:

On another note though, are there any way to traverse the tree downwards, or do I have to find the first upgrade, then loop through every upgrade and see if the one I found is a requirement? Otherwise just keeping an internal list and adding to that every time a new upgrade is available?

IMO the easiest way is to just fetch all upgrades with the first request (via ?ids=all), then delinearize the objects into either a tree or an edge table. vis.js wants an edge table, so that’s what I’ve done in the example. But yeah, you basically have to do it yourself (sorry).

Also as an aside, vis.js is much more awesome than I expected it’d be.

Holox.3528:

It must not be hardcoded. We are able to check the prerequisites of each upgrade and compare them with the IDs of the “vendor upgrades”.

Right, but determining which upgrade vendors are player-accessible is an exceptionally difficult problem — without pulling in a whole bunch of dependencies (e.g., large parts of the game logic) the implementation would just be a whitelist of “these vendors are player-accessible, look at their upgrade lists to determine which vendor sells which upgrades”.

Hey all,

To better communicate API changes and developments with application developers, we’re trying out gitter. Gitter is basically an in-browser chat with github integration — to use it you’ll need to create a free github account if you don’t have one already (although I think that’s only if you want to post messages).

This is in addition to the forums and github and everything else; feel free to use whatever you’re comfortable with to voice your concerns/feature requests. The more the merrier

Yep, you guys are right. Thanks for double-checking me on that — went through the code for the /age command and figured out where we’re storing that data.

Ahlec.8423:

Hey! I’m really liking how fleshed out the API is becoming, and I was wondering: for the /account authorised endpoint, will total play time across all characters as well as current account AP be added in the near future? Calculating the former based on the playtime of all characters sounds like a workaround but doesn’t take into account characters which were deleted and are no longer providing data.

I just thumbed through the game code and am pretty sure we don’t actually track per-account play time — only per-character play time. Let me know if that’s wrong, but I’m not seeing a field for it anywhere in the account data.

The total AP is actually not a bad idea; I’m not sure why I didn’t add that yet. It’ll probably require the “progression” permission to match a related upcoming change. I’ll make a tracking issue on github for it later.

Drifyt.2598:

Specifically, in your own experience, how often would you say an item changes? Is there anywhere that changes are noted? I would assume after each patch? I am unsure if items can change mid version.

To add to Eearslya’s response, items cannot change unless the value of /v2/build updates — that’s the only time that the dat-reading component (from which anything with localized data originates) pulls updated data. For endpoints that are localized, if /v2/build hasn’t changed since the last fetch, the same data will be returned.

It’s a bit annoying, but our API backend is totally stateless so there’s not a good way for the API to respond to If-Modified-Since requests (or respond with Last-Modified). This issue has been raised a few times in the past (and I opened a github issue today to track it better), but my current recommendation is to do a complete re-fetch of any data persisted by the application from localized endpoints whenever /v2/build updates. There might be a better way to do this in the future, but right now that’s the only recourse available for application developers to always have an up-to-date version of the data.

BugsBanni.1397:

I just wanted to tell you, that the festival dailies aren’t listed when calling the Daily API. Nothing I really need atm, but a bug

Bleh, thanks for the report, I didn’t think to check that with Wintersday. Probably won’t have it fixed until the next festival. Made a Github issue to track the bug.