(edited by darthmaim.6017)
Yep, it still can be someone else, but at least the owner knows about it, because he created the key for someone else. Or in the rare case someone got access to the account and created a new API key, the user at least knows for which site the API key is used, because most apps require names that include their name/domain.
This is probably not needed for some apps, but for all those WvW apps for example its important to be sure the user is really on that world (currently, they also could create free accounts on that world to circumvent it, but /v2/account will hopefully contain the account type soon).
Why force users to use a specific api key name? What benefit does that provide?
Forcing a new unique key name each time has the benefit that we now its a newly created API key for exactly this new app, and not some key someone found on the internet, got from a friend, …. The user owning the account is the only one who could create it, so we know its the right person to register the API key with our app.
Now that we have been using API keys for quite some time now, I have to say its not nearly as bad as most people in this thread (including me) anticipated.
OAuth 2.0 has definitely some advantages (easier to create and manage for users), but creating API keys isn’t too bad. And once they are created, API keys are way easier to work with from a developer standpoint, no refresh tokens, callbacks, …, just storing the API key for each user and sending it with each request.
The chatlinks for those are [&AgGOIwAA] and [&AgGXtgAA]. The first one doesn’t seem exist ingame, the second one is Xunlai Electrum Ingot.
API Terms:
These API’s are wholly owned by ArenaNet, LLC (“ArenaNet”). Any use of the API’s must comply with the Website Terms of Use and Content Terms of Use, however you may use the API’s to make commercial products so long as they are otherwise compliant and do not compete with ArenaNet. ArenaNet may revoke your right to use the API’s at any time. In addition, ArenaNet may create and/or amend any terms or conditions applicable to the API’s or their use at any time and from time to time. You understand and agree that ArenaNet is in the process of developing a full license agreement for these API’s and ArenaNet will publish it when it is complete. Your continued use of the API’s constitutes acceptance of the full license agreement and any related terms or conditions when they are posted.
So based on the “you may use the API’s to make commercial products so long as they are otherwise compliant and do not compete with ArenaNet” I’d say yes (IANAL).
Yes, f2p accounts can currently make API keys. But I keep getting “ErrInternal” when trying to access authenticated API endpoints with my test account I just created (/v2/accounts).
Tokeninfo works fine.
Edit: Seems like I needed to create a char first. It’s all working now.
(edited by darthmaim.6017)
Awesome! There a quite a few great things we can do with those.
Did I miss something in the documentation?
Yes, pagination.
You only get the first 50 results returned per default, you can get up to 200 by setting the query parameter page_size=200. To get the next 200 entries, you then can use page=2 (and so on). Take a look at the response headers, they tell you how many pages there are.
Wiki: http://wiki.guildwars2.com/wiki/API:2#Paging
Yep, I guess it’s related to the broken flags atm, the cached version I use for gw2treasures still contains the flag: https://en.gw2treasures.com/item/42426/json.
42426 has the flag “NotUpgradeable”.
Shameless self-plug: If you don’t want to miss any new endpoints or other announcements, but don’t want to read every single comment here or on github, you can follow my twitter account I created for exactly that: @GW2API.
You have to use the /v2/traits endpoint to lookup traits. It’s currently still in development, but a preview is available at /v2/traits-beta.
You can follow the development and discussion about /v2/traits in the github issue: https://github.com/arenanet/api-cdi/pull/67
On https://api.guildwars2.com/v2 you can see a list of all endpoints.
(edited by darthmaim.6017)
There is no request rate limit, but I am getting a lot of 503 recently too. Almost half of my requests are failing.
HTTP/1.1 503 Service Unavailable
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 01 Aug 2015 22:34:25 GMT
Connection: close
Content-Length: 326
Great work on letting the items from vendors (and elsewhere not before obtainable via API) begin to flow into the items API. My updater scripts have been pulling in new IDs all night.
Huh? I only had 2 new items in the last few days?
Hi everyone,
As explained here, we’re going to progressively move this stickied thread to the official Guild Wars 2 wiki.
I started populating the page using the links in this thread (but am probably missing less than a week of data):
http://wiki.guildwars2.com/wiki/API:List_of_applicationsFeel free to join the API editor group on the wiki to add your own application (specifically to this page and using the same format used) or maintain the page above ! You can leave comments about this on the forum thread I linked above or directly get in touch with me via forum private messages. Thanks.
And the wrappers are now here: http://wiki.guildwars2.com/wiki/API:List_of_wrappers
(edited by darthmaim.6017)
You could parse https://leaderboards.guildwars2.com/de/na/wvwmain until there is a dedicated API endpoint for that available.
I just checked and it seems the only items that have been removed are these: https://gw2wbot.darthmaim.de/itemlist.php?id=39925,40898,40914,40922,40930,43948,43949. (Those are the item ids my updater for gw2treasures logs when trying to update all items.)
https://github.com/arenanet/api-cdi/pull/36#issue-89412755
It’s missing the gathering tools’ charges which will be added in a future PR.
Also some discussion about that here: https://github.com/arenanet/api-cdi/pull/16#issuecomment-77876109 and following comments
Use the discussion page to request changes to the list, someone with the API namespace editor rights will edit the list.
I will throw some more documentation with some better examples for my wrapper up over the weekend
Took a little bit longer, but its there now: https://github.com/GW2Treasures/gw2api#usage
You can use the mumble api without having overwolf or mumble installed, as far as my understanding goes. I haven’t tried it, but in theory you can access the specific shared memory from every program the same way mumble does. But you have to run your app on the client and can’t use the mumble API on a website.
curl is the right way to go, you can check the status code and the potential error message to determine if the result is ok. I also recommend guzzle on top of curl, it’s easy to make multiple parallel requests (instead of working with curl_multi directly).
I’m aware about wrappers, but there are so many on the wiki and I couldn’t decide on which one. Since you are offering yours, I will assume yours is the best and most up to date and will gladly use it once I finish understanding this thing called API
Doing it yourself first is a great way to learn how it works! But we don’t have to make it harder on ourselves by reinventing the wheel every time
I really don’t want to advertise my wrapper, but most wrappers on the wiki are still using the old v1 API and/or don’t support the authenticated endpoints. I’d say try some out and use the one that you like the most. (I will throw some more documentation with some better examples for my wrapper up over the weekend)
Or you could use my API wrapper that throws a AuthenticationException with a correct reason. https://github.com/gw2treasures/gw2api
(I have to add better documentation for that still)
—
Your example would be:
$api = new GW2Api()
try {
$characters = $api->characters('api_key')->all();
} catch(AuthenticationException $exception) {
// echo error message
echo $exception->getMessage();
}
(edited by darthmaim.6017)
Would it be possible to get the current number of charges on a consumable item; salvage kits, gathering tools?
Gathering tool uses aren’t currently pulled out of the character data, but it’s something I can look into adding.
(source)
—
I’ve been thinking about this; I think I’m going to add a “builds” permissions that grants access to traits/skillbar/equipment — such that you can get the “equipment” with either the “builds” or “inventory” permissions.
It might be kind of gross like that, but having it enabled by “inventory” allows the “dude-wheres-my-mini.com” use-case for solving “which character has my ascended gs?”
If you wanted to make an endpoint just for builds, perhaps all that is necessary to give is the stats/runes/sigils of the armor and weapons, rather than the actual items and skins equipped?
Lawton was talking about a new permission, not an endpoint. Both the inventory and build permissions give access to the endpoint /v2/characters/:id/equipment.
What does this ‘in-game rank permission that grants API access’ mean?
I think it’s a permission in the rank system (like guild vault access) that grants the member access to guild information with the API, not the other way around and definately nothing for public access. At least that’s how I understood it.
That also what I am thinking.
To get character info you will probably always need the API key of the owner-account, you will only be able to get guild informations with the ingame permission.
maybe a stupid question, but would this then also mean we are able to get an image of the character, maybe even an 3D object?
Rest assured, this is something I really, really want too. There’s a lot of moving parts that need to be ironed out before it’s feasible though, so we’ll probably be sticking to low-hanging fruit for awhile yet :<
—
In addition I was wondering if Authentication would also get an update to allow more options for guild. So we could also use this character information for guild-members. At this moment authentication is done based on your own account-details, but that would mean (correct me if I am wrong) that I would not be able to get this information from anybody else then myself. So I cannot make a guild-roster (I know we are getting a function to get the guild-roster) where (for example) we then show the characters or the guild-members and their gear.
With respect to privacy, the conclusion was that the best solution is to have an in-game rank permission that grants API access. Since that’s going to take some time to implement, the initial release will be restricted to allow access only to guild leaders.
No. But you could create a new proposal on github to get it added.
I completely agree with @lye though, there’s so many useful & way easier things we should work on first.
Going to close this for now, not because we won’t do it, but because it’s far enough out that we should wait until we’re able to give it the attention it needs before spending too much time thinking about it.
Source: https://github.com/arenanet/api-cdi/pull/43#issuecomment-115002068
Awesome! I had the same idea a while back and I must say your implementation turned out great.
I admit, haven’t logged in with those characters for ages.
This is awesome, thanks!
Edit: What is up with all those (mostly non existing) items in characters “equipment” without a “slot” (IDs 62,63,64,…)? Some of them seem to be old town clothing (ID 36370) and some old PvP weapons (have PvP Sigils as upgrade, (ID 5365 with upgrade 21207)).
(edited by darthmaim.6017)
Uhh, I’m pretty sure that’s a bug. Right now we display items that have been looted or bought off the trading post. Should add “bought by a vendor” as another way to get on the whitelist.
That is already coming: https://github.com/arenanet/api-cdi/pull/33
Yeah, thats what I am doing now
How long is this endpoint cached?
When using this endpoint to verify ownership of existing API keys I don’t want that my users have to wait (long), so maybe you could lower the cache time for this endpoint or even disable it. There is no reason this endpoint should get spammed with requests and I guess since it isn’t using any game resources it shouldn’t be too expensive.
I think those are all items that were at one point sold on the trading post. Not necessarily all items that can be traded.
If an item doesn’t exist in the commerce systems, then it has never had a sell order placed for it.
This is to prevent people from placing buy orders for items before there are any being sold and thus influencing markets that don’t exist yet.
I don’t really care for a ‘Accept-Language’ header, the lang parameter can do everything we really need and is way easier to work with (Just think about all the ajax calls that will break because the developer is not sending a the header, but the browser is using the system language, and the application expects the response to be in english).
For now validating the language against [de,en,es,fr] before sending is easy enough, or if you’d want you can check the ‘Content-Language’ header.
Ah you are right But requesting with page_size=50 gets me the same order as /characters most of the time (60-70%), only sometimes the order seems the be random.
If you call /v2/characters you get an ordered list (by date/time of creation)
No. They are not order by creation time. Its the same order I get when requesting a page, although it doesn’t seem to change as often when requesting it repeatedly.
I still would like to see creation_time and a unique identifier for characters though.
[…] character GUIDs are strictly secret. We could theoretically pass them through a one-way transform (e.g., a hash function), but I think it would take significant backend work to plumb that through everything. The character name is at least unique; the mutability is just a constraint I think we’ll have to live with.
I’ll spend some more time looking into it though. It’s a really horrible constraint to live with.
~lye (source).
Can we have an array of permissions?
I just created a new Proposal to add a new /v2/permissions endpoint.
There is no difference between ids=1,2,3 and page=0&page_size=3, in both cases you are getting a subset of all total available items, X-Result-Count tells you how many you got in your queried result, X-Total-Count tells you how many there are in total.
I think that makes perfect sense and I’m not quite sure what your problem is exactly.
The same happens when you request a page (?page=0&page_size=3), you request only 3 items but still want to know how many there are in total. page=x and ids=x are just used to specify which portion of all entries you want.
If you could post your calculation here you could save someone with the same problem some trouble in the future.
And to all the “API-Key-Hater” (for a lack of better wording), you really should look how EVE and CCP do it. It is an awesome system and they have ran with it for years and never had any big problems.
EVE is using OAuth: https://developers.eveonline.com/resource/single-sign-on
Previously we had a link “Click here to login with your Guild Wars 2 account”, now we have “Click here to login to your Guild Wars 2 account, create an API key with the permissions X, Y and Z and then come back here, paste it into that input and in case you did something wrong, do it all over again”.
It is only harder for the user, and every malicious site/app can still link to a fake login screen. I really don’t see how that is supposed to help with phishing. (Except for a few users saving their API keys in a password manager. But those few responsible users would probably want to generate new keys with specific permissions for every app, so they’d need to reauthenticate anyway. And they would probably not fall for phishing in the first place.)
TL;DR of the remaining post: Users are lazy, UX is horrible, doesn’t fix the phishing problem, OAuth was better for everyone.
OAuth was easy to implement (with thousands of tested libraries available for all languages/frameworks) and had great UX for users. API keys are horrible UX-wise. There are just so many scenarios that just don’t work well with API keys.
1.) Most Users will just generate 1 key with full permissions and reuse it for all apps. Once they want to revoke access to their account from one app (and the app doesn’t provide an easy way of doing that in the app/the user doesn’t trust the app to completely remove the key), the users has to generate a new key and reenter it in all other apps he uses. (There could be quite a few “passive” apps he doesn’t often visit and only notices the errors months after).
2.) An app requires the permissions X, Y and Z, but the users forgets that by the time he has logged in to the account page (can take quite some time: 2 factor, email for unknown IP, looking up password in password manager/phone/notebook, …) and only allows access to X and Y. Now the users has to do all that again after entering the API key in the app and getting an error. Maybe he was using private browsing and has to do the login to his account page all over again.
3.) An app requires new permissions after an update, the user now has to create a new key and enter it again, maybe even for multiple apps that required the same permissions before and he was sharing the key for.
4.) You create a new scope for the API, the user now also has to update all apps in case he only uses one key for all apps. And no matter how much we tell the users to generate new keys with specific permissions for each app, most users won’t do that because they are lazy and don’t see the problems of it in the future.
5.) Probably way more than that, those were just a few off the top of my head, but we will run into more problems once we are using them…
OAuth had easy solutions for most of these problems by simply doing most of it behind the scenes, leaving the user no way to mess up. Just clicking one button and the app had all required permissions with an easy way of updating/revoking permissions per app.
I know OAuth has some flaws, but API-Keys for users that don’t understand them are way worse IMHO.
OAuth2 is working great for me, too.
What are your reasons behind thinking about transitioning away from OAuth2 to an API key style system?
v1/item_details
Take the v2/items endpoint and it will be much faster, because you can request multiple items at once.