Guild Wars 2

Wow, yeah, that endpoint is totally broken. I did a big deploy on Friday which probably contained the break — the error is because it’s reading cached values for other quantities. I’ll have that fixed today.

EDIT: Just deployed the fix for this.

Not currently, no. I’m really tempted to just throw that achievement category into /v2/achievements/daily since it’s kind of a daily and everyone considers it to be one. Doing that would make tomorrow’s visible as well.

Thoughts?

That’s super weird, but I think you’re right. Really need to figure out what events to watch for to make those go into the whitelist queue properly. Just whitelisted the following items:

78938, 78882, 78891, 78851, 78998, 78825, 78962, 78937, 78947, 78982, 78899, 78933, 78898, 78836

Yeah, an endpoint that can do character renders is on my wishlist. It’s quite a project though; not sure when I’ll get around to it.

I forgot to go through and whitelist the new items/achievements/recipes/etc — it’s a woefully manual process. Just went through and blessed all the ones that were pending.

The orphaned/empty achievements are content issues. They’re not displayed in the in-game achievements UI, but they are counted towards your total AP. I don’t have any insight into content changes, so I’m not sure why they’re not displayed or if/when they’ll be fixed, unfortunately.

For some reason that one and 427 fell out of the whitelist. Not really sure how/why, but I added them back in.

Eugh, those are actually test items, not the actual unlock items. There’s a bug in the backend component where, when scanning for which items unlock which minis, it only saves the first one encountered. It’ll take awhile to get the correct fix through the release pipeline, but here’s the tracking issue.

In the meanwhile, I’ll try to get a bandaid patch in this week so those two minis have the correct item id. Thanks for the bug report!

I asked around. Our billing partner, Digital River, has a Russian localization. The button to switch languages for that form is on their side and they haven’t disabled it. That page is AFAIK the only place that has a Russian localization.

Fix for this should be live now.

The current configuration for cache times are:

• /v2/commerce/listings – 1 minute
• /v2/commerce/transactions – 1 minute
• Everything else – 5 minutes

Kinda confused by this; I thought listings was at 5 minutes and prices was at 1 minute. Might switch that around.

The cache times are returned in the Cache-Control and Expires headers in the HTTP response.

I’ll see if I can get a workaround for that in on my side today or tomorrow — it crops up when some of the backend servers get restarted. In the meanwhile, logging in with the game client should make the account’s keys work again.

At some point, yeah. There’s an open issue on github for this. (EDIT: also this one for backstories).

There’s no rate limit on our end. Be advised though that pulling all items every 5 minutes is probably unnecessary — the existing items won’t change unless the build id from /v2/build increases and new items are only added by hand (infrequently).

It hasn’t been implemented yet; there’s an open issue for it.

There’s a proposal for this on github; I haven’t had the time to implement it yet though.

Oops, those extra added achievements were a fat-finger on my part. They’re all stuff that was cut or not released or unfinished, including that “Treasure Hunter” achievement (there’s another one with the same name in the rare collections category).

I’ve taken the liberty of un-whitelisting them, sorry about that.

Wow, I can’t believe I missed that.

I’ve made a tracking issue on github, I should have that fixed sometime next week.

The fix should go out with the next release (e.g. the next patch that is not a hotfix). It takes awhile to push changes through the pipeline is all.

The non-transient errors are supposed to be “invalid key” (key doesn’t exist), “banned key” (we’ve blacklisted the key on our side) or “broken key” (something horrible has happened).

Looking at the code, there may be an issue where “invalid key” is incorrectly returned during a temporary failure — need to root around in some code to check what situations can cause that.

In any case, this is definitely not documented well and we really should be returning 5xx responses for transient failures. I’ve created a tracking issue for both the audit and better docs; I would keep seemingly broken API keys around until this gets resolved. Sorry about the hassle

The short answer is no.

There’s an open issue on github for this; the unfortunate bit is that the API frontend is entirely stateless (so it can’t persist data) and the backend that reads the dat file can only run the latest dat file (and is effectively also stateless) — and the dat file doesn’t have any versioning history.

So, to implement this on our side we basically have to rearchitect how data is obtained for a large portion of the API (basically, any endpoint that accepts a ?lang parameter). It’s something that I’d like to do at some point, but am currently unable to justify the massive amount of time it would take to implement.

I think the easiest solution is for end-users to basically clone the database (e.g., pull everything when /v2/build updates) and track changes locally. I realize that this is totally infeasible for webapps, but it’s the only avenue I can offer right now.

Sorry :<

stress level zero.4907:

Lawton Campbell.8517:

I found and fixed a bug awhile back that would cause issues like that for the first request once/day or so (when the session created for the token would expire). I haven’t personally seen it happening anymore, but let me know if you’re still seeing it and I’ll investigate some more.

Hey Lawton, this happened today.

Received an unexpected 400 response:

http://i.imgur.com/umE1OXw.png

Thoughts?

https://github.com/madou/armory-back/blob/master/gw2-fetch/src/controllers/ping-controller.js#L95

I guess I’ll disable deleting the token for now.

Actually, I think we might have done a server deploy around that time — one of the backend servers the API talks to was timing out over two windows last night. Do you happen to have the error text returned by the server? There’s a lot of reasons a key can be invalid (and they all return unique error strings).

Thanks for that list, that’s super helpful. There’s a longstanding bug in one of the backend servers that causes it to erroneously return items it shouldn’t — in the meanwhile I’ve added those ids to the blacklist so they will stop appearing in the list.

Yeppers, we just updated the trading post backend which fixed a longstanding bug that the API had been unwittingly abusing. I’m pushing out a fix that makes the API do the right thing. Here’s a tracking issue.

EDIT: Deployed the API fix which should have corrected the issue. 19717 no longer shows up in the listings.

Anhim.3156:

I’m not sure if this belongs here, but there seems to be an issue with https://api.guildwars2.com/v2/skills/6084?lang=fr and https://api.guildwars2.com/v2/skills/6084?lang=es

Both the ‘en’ and ‘de’ versions of the skill work fine, but ‘es’ and ‘fr’ through some oddball errors.

Whoops, sorry about that. Just deployed the fix.

Nokomis.5076:

Then again I also read that daily achievements should be whitelisted automatically.

I haven’t gotten around to implementing that, so I’m still doing it by hand (and forgetting, as it seems).

Yeah, that’s one of the level 80 boost items.

The coin rewards are a fairly new feature, probably why it’s not documented on the wiki yet. I don’t have edit rights on the wiki’s API namespace; I’ll look into getting that today.

Those have also been whitelisted. There’s an open issue for this; I basically need to set up a cron job or something that automatically whitelists tomorrow’s dailies on reset.

Those recipes don’t produce items — they produce guild upgrades (indicated by the output_upgrade_id field). The output_upgrade_id field can be resolved against /v2/guild/upgrades to get the details. There’s an open issue for this since it’s kind of a mess, but I didn’t want to break existing applications so that field’s been left in for the time being.

63366 was a rune that got cut prior to HoT shipping, but wasn’t actually removed from the game (and you could buy them on the trading post and stuff). I’m not sure what the plan for the rune was but I suspect there are still some instances of that item floating around.

bobsort.4097:

It seems last “/” causes a redirect which removes the key from request.

That’s a bug; here’s a tracking issue. It’s probably all the authenticated endpoints, not just /v2/characters. I can probably have that fixed in a week or two, in the meanwhile I recommend not sending the trailing slash in requests.

stress level zero.4907:

Has the false negative bug been fixed where the api would return 40x responses for valid tokens on the characters endpoint?

I found and fixed a bug awhile back that would cause issues like that for the first request once/day or so (when the session created for the token would expire). I haven’t personally seen it happening anymore, but let me know if you’re still seeing it and I’ll investigate some more.

I’m pretty sure this is being caused by dailies being flagged as HoT/non-HoT, and that flag isn’t currently exposed via the API. There’s an open issue for this, I need to go back and see what the current state of my implementation is (it fell off my radar, I think).

Reincarnated.1754:

API:2/wvw/objectives

coord location of “Overgrown Fane” and “Thunder Hollow” incorrect.

Screenshot

Thanks for the heads up, here’s a tracking issue. Probably going to require a content change, so the fix won’t be out for awhile

I spent some time today making my “make sure we don’t leak things while updating the tile data this time” test app presentable and pushed it to the api-cdi repo. On the WvW maps it renders the objective markers from the API data and such.

The ruin names have been bugged for awhile (tracking issue); with Alpine BL back I need to root around and see where those map labels are coming from. For all of the other objectives, the labels are from the sectors that the objective is in (and the objectives have no name associated with them).

The tile cropping is just an artifact of how the tiles are generated — basically with a program that just takes screenshots of the world map UI element. I think the Alpine BL was adjusted to have different bounds which causes there to be no parchment beneath EB. It’s a bit unfortunate, but a bit intractable.

Drant.5902:

In case we do get map rotations often, it would be nice if there is a variable in the wvw/matches endpoint that tells whether we’re having Desert or Alpine currently. Right now the way to determine that is to read the objectives array (which contains respective objectives).

In /v2/wvw/matches, each map object in the .maps array has a id — which somewhat ambiguously is the map_id — that you can inspect or resolve against /v2/maps to get the metadata and localized strings.

EDIT: also the new map tiles are up.

Investigated this a bit; the fix is actually pretty complicated. I’m not sure if/when I’ll be able to fix it, unfortunately, nor do I have a workaround in the short-term. I’ve made a tracking issue on github for this.

In the short term, I’m uploading the regenerated tiles right now. Should have the Alpine BL tiles up by the end of the day.

In the middle term, your proposal sounds reasonable if a bit of a hack. I’ll look into setting it up sometime this week. I opened up a tracking issue on Github for this.

Just whitelisted it.

bxt.7691:

There have been a number of threads about this specific issue already, I think the best approach discussed was a special permission added but I’m not sure of anything that happened beyond that.

FWIW, that’s still the goal.

Adding the missing subendpoints seems reasonable; added a tracking issue.

Specialization icons that override the profession icon are in /v2/specializations for ease-of-use (and the default profession icons are in /v2/professions). Made a bit more sense to me to do it that way.

I just pulled the kills/deaths for match 1-2 and they looked like this when I fetched them from the API:

	"deaths": {
		"red": 55369,
		"blue": 49319,
		"green": 51870
	},
	"kills": {
		"red": 61143,
		"blue": 49876,
		"green": 37534
	}

Using the above data, the total deaths with these counts is 156558, the total kills is 148553. The logic used on the map instance server for counting kills/deaths is detailed in this post — total deaths should always be higher than total kills.

It’s totally possible there’s another horrible bug with how the API interprets the counts from the map instance servers (last time it was including OS kills/deaths in the total counts); I don’t see the issue currently manifesting though.

/v2/materials only shows crafting materials that can be stored in the account’s material storage (the contents of which is available via /v2/account/materials). To get a list of all “CraftingMaterial”-type items, you need to enumerate /v2/items.

Guild favor (and the other guild currencies) aren’t currently available via the API. There’s an endpoint that isn’t turned on (don’t remember why — probably needs more testing) that exposes it; I can look into enabling it sometime next week.

Inimicus.7162:

Curious if this also applies to the “Canach’s Backpack” item in the wardrobe, because I haven’t yet run into any way of getting that one either. And it’s been in there for a very long time now lol

But that one’s not in the API.

I can only answer API questions :>

Hypothesis confirmed correct. Only one person has ever gotten the PvP Destroyer Scythe, and it’s a GM.

Hype train derailed :>

You need an API key with the “builds” permission, then the utility skills show up in the “.skills” field. Example.

Ah right, forgot about that.

I’ll probably have that turned on by mid next week.

Malediktus.9250:

Sariel V.7024:

Did that include the Destroyer Scythe? Seems it popped up for some reason.

The pvp destroyer scythe was most likely a manual whitelist (or a GM playing around). It cannot be from mystic forge

That’s the most probable reason. I’ll see if I can find some time to dig through the logs and figure out where that came from. Given it’s a PvP weapon, it was almost certainly spawned in by a GM or customer support.

Nekres.1038:

Uhm, does the data update somewhat slower? My deaths went from 5 minutes intervall updates to almost 20 minutes!

Should still be ~5 minutes. There’s an edge case where the map instance server hasn’t persisted character data to the database (IIRC that’s on a 5 minute timer, or when you switch maps or sell something on the trading post etc) and that stale data gets pulled in and cached by the API backend for another 5 minutes. So to the best of my knowledge, the maximum staleness should be around ~10 minutes (though only under special circumstances).

It’s altogether possible there’s a bug somewhere causing data to be cached too long. If the issue doesn’t clear up, consider opening an issue on github (or just posting again here).

Fix went out with today’s hotfix and works correctly; just turned the /v2/characters endpoint back on.