Pat Cavit.9234:

Welcome to the 2015 API CDI thread!

This is intended to be a slightly more structured location for us to discuss the various current & upcoming public APIs. In the past these threads were scattered all over the place (though the old suggestions sticky has some useful links) and I’d like to centralize things a bit. Especially as we start shipping the first of the authenticated APIs it feels like the right time to start this process.

So here’s how I’d like this to work.

  • Discussion around more philosophical topics like future APIs, high-level details, etc will be handled in this thread.
  • Actual API details (fields, formats, etc) will be discussed via pull requests against the api-cdi GitHub repository. These provide trackable history of changes as well as cleaner formatting options.
  • Try to keep your posts relatively brief. Giant walls of text are hard to parse and discuss succinctly.
  • Other CDI caveats and warnings apply. In the API forum we try to be more open about what we’re working on, but things change quickly and we try to spend more time working than posting.
  • If you’re going to comment on a PR on the forums instead of on GitHub, quote the exact commit you want to discuss.

Example post commenting on a commit:

I think that lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse commodo augue sit amet augue fermentum maximus. Suspendisse eu faucibus neque, sagittis bibendum arcu. Mauris hendrerit.

The most important thing to remember is that this whole idea is a work in progress! We’re open to modifying the process based on your feedback.

Current Proposals

dlonie.6547:

One API endpoint I’d like to see would provide access to historical trading post data — for example, to get the data to produce a graph similar to those on gw2spidy, gw2tp, etc.

Doing this currently requires constructing an external database and scraping the APIs regularly to populate it, and data from before the scrapes started is never accessible.

Before putting up a proposal for the endpoint parameters and response format, would something like this be possible? I.e., does ArenaNet store a detailed history of trading point data? Would the sheer amount of data that would potentially be pushed through their servers be problematic?

And thanks for starting this Pat — the APIs are one of the coolest things about this game for people like me

Pat Cavit.9234:

One API endpoint I’d like to see would provide access to historical trading post data — for example, to get the data to produce a graph similar to those on gw2spidy, gw2tp, etc.

Doing this currently requires constructing an external database and scraping the APIs regularly to populate it, and data from before the scrapes started is never accessible.

Before putting up a proposal for the endpoint parameters and response format, would something like this be possible? I.e., does ArenaNet store a detailed history of trading point data? Would the sheer amount of data that would potentially be pushed through their servers be problematic?

And thanks for starting this Pat — the APIs are one of the coolest things about this game for people like me

Lawton’s got a proposal for a user-specific TP transactions history endpoint he should be putting up as a PR. We need to get authenticated APIs up & stable before that API can become a reality though.

AFAIK we don’t track historical buy/sell data for items on the TP due to not having a need for it & it’s a lot of data. Something I can double-check though.

MithranArkanere.8957:

All I want for now is just 3 things:

  • Some sort of authentication, so the API can get permission to get info about an account and its characters.
  • A way to get the info of all copies of a map, and the info of a particular copy of a map. Combined with the authentication and the events API, it’ll be able to tell you the event of the particular copy of the map the current character of an account is in just like before megaserver.
  • Also combined with the authentication, a way to pull contact lists, and be able to pull the locations of the reciprocal friends of that account if they are in the same copy of the map.

Elrey.5472:

Something that i’d like (but i don’t know if you guys want or can provide) is an API for enemies information such as:

  • Enemy skills (to check their cooldowns and effects) .
  • Enemy stats (base stats, not scaled ones).
  • Enemy buffs
  • Other enemies information.

This information could be used to understand a fight better than guessing, which is a problem sometimes.

anzenketh.3759:

Due to the frequency of changes to skills it is hard to create a build calculator. It would be nice if we had a API that gave us skill information.

darthmaim.6017:

I might try to go through the old suggestion thread this weekend and create issues for everything that deserves more discussion.
It’s great that you guys are finally using github, so that it’s easier for us to make suggestions, discuss features and follow updates than it is in a forum.

Cronos.6532:

It would be pretty nice to still be able to use the API to pinpoint which events are taking place on a certain /ip server address; this was removed with megaservers.

Torsailr.8456:

All I want for now is just 3 things:

  • Some sort of authentication, so the API can get permission to get info about an account and its characters.
  • A way to get the info of all copies of a map, and the info of a particular copy of a map. Combined with the authentication and the events API, it’ll be able to tell you the event of the particular copy of the map the current character of an account is in just like before megaserver.
  • Also combined with the authentication, a way to pull contact lists, and be able to pull the locations of the reciprocal friends of that account if they are in the same copy of the map.

Is it possible to take this a step further?

Be able to get a list of what events are active, or the timers on the inactive events for all instances of a given map?

IE, if I wanted to do Balthazar but I’m in Queensdale. Being able to see if there are any instances in progress or about to start would be nice. This would make it easier for people to organize on specific maps to do these events.

Samuirai.4561:

I believe the GW2 API is great, but too passive. This change would allow players to actively interact with their characters.

BLUna.7928:

Some PvP API would be fantastic. I think it would be really cool if we could potentially create something like dotabuff but it just does not seem possible at the moment. Being able to access things like match details (kills, deaths, points, builds players were running) would be fantastic not only for match sites but also for things like post game breakdowns in tournaments.

Samuirai.4561:

gw2spidy, gw2tp, etc. allow us to see historical prices. It’s not ideal but ok. What we lack is a API that gives us the amount of transactions that happened in a set time frame. Example:

/v2/commerce/transactions?ids=1234

{ “listed”: 9999, “ordered”: 1111, “sold”: 5555, “bought”: 5678}

Historical data on this would be great too, but it’s enough for now to have updates every minute or every 10 minutes, so we can populate our own databases.

dlonie.6547:

Lawton’s got a proposal for a user-specific TP transactions history endpoint he should be putting up as a PR. We need to get authenticated APIs up & stable before that API can become a reality though.

O.o really? That would open up oh-so many possibilities for me. I hope this happens quickly, though I imagine it won’t be one of the first ones tested +1 to this idea!

AFAIK we don’t track historical buy/sell data for items on the TP due to not having a need for it & it’s a lot of data. Something I can double-check though.

I’m somewhat shocked to hear that — I’d have thought the economist would have wanted this info stored somewhere for various reasons. Looking forward to hearing if this is doable!

What we lack is a API that gives us the amount of transactions that happened in a set time frame. Example:

/v2/commerce/transactions?ids=1234

{ “listed”: 9999, “ordered”: 1111, “sold”: 5555, “bought”: 5678}

This is a solid suggestion I’d like to see as well. There’s really no good way to get at this information, in game or otherwise, and it’d be very useful for various market analyses. I’ll add that the “bought” and “sold” quantities should ensure that pulled listings aren’t counted, as that’s an issue with how we’re currently trying to measure these things (using the naive approach of diffing the listing quantities).
Thanks again!

Teranas.6150:

I would love to see Trait and Skill endpoints. I think those information should have been part of the API since v1.

Those endpoints would let us develope better build constructors and BBCode plugins for our forums.

They should provide information about the behavior of skills and traits.

title
description
damage modifier
conditions
boons
radius
stun(breaker)
max distance
combo effects
target count
casttime
cooldown
references to applied (de)buffs
type of skill (utility, weapon skill)
corresponding class
corresponding race

And of course: references to their corresponding icon files. I really think i missed some important infomation that should be included …

I may write a pull request for this if no one else will do it.

aRestless.6213:

First of all thanks a whole bunch for doing this! As a developer it is very encouraging to hear that you do your best to support us a bit more!

My project heavily relies on the Mumble API and it would be fantastic to have some additional information through the web API to better deal with what I already get, for example

  • Information about the (vertical) dimensions of floors sufficient to convert from player position to floor
  • Zoom Level Information for dungeon maps. For example: Ascalonian Catacombs are on continent Tyria and therefor should have 8 zoom levels, but since dungeons have their own map view, ingame there are only 2 zoom levels. Arah has 4.
  • Zoom Level to magnification factor. For Tyria I pretty much figured the magnification factors out by myself, but they seem to differ a bit between Tyria and the Mists … and of course dungeons.

I apologise in advance if any of these are already possible – I’d be grateful for any advise. Additionally, from authenticated APIs I’d welcome two basic things:

  • Currently represented guild
  • Home Server for WvW (since Megaservers the Mumble API seems to be broken in that aspect)

Also I’m hoping for a Single Sign On solution for authentication … because account theft is a bad thing.

poke.3712:

Also I’m hoping for a Single Sign On solution for authentication … because account theft is a bad thing.

For the authenticated API, OAuth2 will be used. So you will have the standard login on account.guildwars2.com, just like with the forums, to authorize applications to use your data. You could even use this as a sign-on functionality for applications that don’t use the API at all.

Pat Cavit.9234:

/v2/skills is something Lawton’s been working on for a bit. Due to the way they’ve been organically constructed over time it’s a real hairy thing to make skill data be as regular as you’d want in an API. A proposal for that should be going up in the near future.

All authenticated APIs will be using OAuth2 and authenticating against https://account.guildwars2.com, yes.

Teranas.6150:

/v2/skills is something Lawton’s been working on for a bit. Due to the way they’ve been organically constructed over time it’s a real hairy thing to make as regular as you’d want in an API. A proposal for that should be going up in the near future.

Very nice to hear!

AfterXII.2761:

As a guild leader and a web/phone app developer, I took a look at the announcement of API authentication and immediately thought of the following possibilities for new implementations:

Personal Account

  • Personal bank contents, assets, wallet, etc
  • Current guilds (with flag on current rep)

Guild

  • Roster endpoint
  • MOTD endpoint
  • Guild bank endpoint
  • Guild chat endpoint (amazing applications possible with this endpoint)

Lawton Campbell.8517:

All I want for now is just 3 things:

  • Some sort of authentication, so the API can get permission to get info about an account and its characters.

I put together a PR about upcoming /v2/account API. The PR has more details, but it’ll give you the ability to authenticate users and determine their homeworld (and eventually more stuff is planned for it).

Wanted to have it released this week, but having some fun technical issues with the deployment.

As a guild leader and a web/phone app developer, I took a look at the announcement of API authentication and immediately thought of the following possibilities for implementation:

Personal Account

  • Personal bank contents, assets, wallet, etc
  • Current guilds (with flag on current rep)

The personal bank account (and material storage) is planned for the /v2/account API (see the PR link above), as is the current guilds an account belongs to. The currently represented guild will probably live in /v2/characters, and the roster in an account-specific guild endpoint (haven’t really sorted out the design for that yet).

Anyway lemmie get some more writeups posted on Github for you guys to peruse.

AfterXII.2761:

All I want for now is just 3 things:

  • Some sort of authentication, so the API can get permission to get info about an account and its characters.

I put together a PR about upcoming /v2/account API. The PR has more details, but it’ll give you the ability to authenticate users and determine their homeworld (and eventually more stuff is planned for it).

Wanted to have it released this week, but having some fun technical issues with the deployment.

As a guild leader and a web/phone app developer, I took a look at the announcement of API authentication and immediately thought of the following possibilities for implementation:

Personal Account

  • Personal bank contents, assets, wallet, etc
  • Current guilds (with flag on current rep)

The personal bank account (and material storage) is planned for the /v2/account API (see the PR link above), as is the current guilds an account belongs to. The currently represented guild will probably live in /v2/characters, and the roster in an account-specific guild endpoint (haven’t really sorted out the design for that yet).

Anyway lemmie get some more writeups posted on Github for you guys to peruse.

Sounds awesome, cant wait!

Immortius.4537:

Basic Metadata APIs

There are a number of basic metadata apis I think it would be nice to have:
professions – Information on the available professions.
weapon_types – Information on weapon types – what they are, whether they are 1-handed, 2-handed, off-hand?
weight_classes – Information on weight classes (heavy/medium/light)
armor_types – Information on armor types (helm/shoulders/helmAquatic/etc)
damage_types – Information on the weapon damage types (physical, lightning, fire, ice)

While these are pretty constant, there is currently no way to get a proper, language specific display name for these things from the API. In some cases the “identifier” used to refer to these things can be a touch confusing (the whole harpoon/spear harpoongun/speargun thing). Additionally it would be nice to link these things up so that for a class you can find out the weight class and usable weapon types.

poke.3712:

There’s not really much use for that. You can just encode that statically within your application and safe heavy HTTP requests that way. As you said yourself, that data is very constant.

If you want, I can write down that data for you.

The Geil.8605:

Some of these are most likely a mix between /v2/account- and /v2/character-data, but I was just brainstorming of all storts of information that would be nice to see somewhere in those.

Account API
	Achievements
	Characters
	Collections
		Minipets
		Outfits
		Mail Carriers
	Skins
		Armor
			Light
			Medium
			Heavy
		Weapons
			One-handed
				Main Hand
				Off Hand
			Two-handed
	sPvP (Account Specific)
		Games Played
			Ranked Games
			Unranked Games
		Kills
	PvE (Account Specific)
		Dungeons
			Stories Completed
			Paths Completed
	WvW (Account Specific)
		Rank
		Kills
		Captures
			Castle
			Keep
			Tower
			Camp
Character API
	Equipped
		Armor
		Weapons
		Trinkets
	Crafting
		Current Disciplines
		Discipline Levels
	sPvP (Character Specific)
		Games Played
			Ranked Games
			Unranked Games
		Kills
	PvE (Character Specific)
		Dungeons
			Stories Completed
			Paths Completed
	WvW (Character Specific)
		Rank
		Kills
		Captures
			Castle
			Keep
			Tower
			Camp
	Build
		PvE/WvW
		sPvP

Divus.3175:

About historical tp data.

Either John Smith has his own server with all (I mean ALL) the data, or you have it somewhere in some form of historic tables. That’s just a wild guess.

About pvp api.

  • current pvp match by account name or character name.
  • past pvp matches, i.e. results of pvp tournament by character name / flag (but I feel there’s no any indicator of so)
  • ranked and unranked statistics – how many games are played by day, what’s the most played map, etc.
  • what’s the percentage of each profession in pvp – statistics

About pve api

  • what’s the missing part of map completion by character (players wants it for such a long time, and api would give a chance to create app showing these stuff interactively)
  • collection by account name

Blumoon.5437:

I’m really stoked about all of this. I’ve had a few app ideas floating around in my head for some time now, but they all require the authenticated APIs. I’m really happy to hear they’re coming soon.

Immortius.4537:

There’s not really much use for that. You can just encode that statically within your application and safe heavy HTTP requests that way. As you said yourself, that data is very constant.

If you want, I can write down that data for you.

I agree it should be stored statically in an application.

However the question is where to source the information. I guess each each developer can go in-game and write it out manually these details for each of the four supported languages. I just feel it is appropriate for completeness to include in the APIs, so we have an easier source for it.

Obviously the upcoming inclusion of a new profession and new specialisations means this information isn’t quite constant either.

Pat Cavit.9234:

About historical tp data.

Either John Smith has his own server with all (I mean ALL) the data, or you have it somewhere in some form of historic tables. That’s just a wild guess.

John Smith has access to offline data querying stuff that isn’t suitable to expose via the API, sadly.

Also his secret is that he really gets most of his data from the fiber-optic cable in his brain that is wired directly to the DB servers in the datacenter. Limits his range of motion quite a bit, but at least his query latency is low.

Lawton Campbell.8517:

Just finished an initial writeup of the current in-dev state of /v2/skills. It’s still quite a bit away from being ready for public consumption, mostly just looking for ways to improve the output format.

About historical tp data.

Either John Smith has his own server with all (I mean ALL) the data, or you have it somewhere in some form of historic tables. That’s just a wild guess.

Querying it is neither fast nor scalable, so it’s very unlikely that we’ll be able to provide access to anything beyond what you can see via the in-game UI. I think the current cutoff for the transaction history is three months, but might be mistaken about that.

Aerodin.2795:

It would be pretty nice to still be able to use the API to pinpoint which events are taking place on a certain /ip server address; this was removed with megaservers.

I second this one. I suspect that it’s not quite that simple on the backend, but if it’s possible, it’d be awesome to get the events api back.

For the future APIs, from a high-level standpoint I’ve been thinking that any APIs that promote community are going to be the most useful. Having access to some of your account information, such as bank contents, characters, etc, is cool and all, but I don’t see them having as wide of an impact as something that enhances the GW2 community.

A perfect example of this is an expanded guild API. I’ll try to post a PR with more details, but I’m picturing an API that provides more details, starting with a roster of players, ranks, map locations, etc. Further expanding that with Authentication could bring guild management features, such as managing player ranks, invites, upgrade queue, etc. It’d be freaking awesome.

aRestless.6213:

Guild management and especially member management can be a big problem in larger guilds. Having Roster and Roster History exposed would be a huge thing.

poke.3712:

However the question is where to source the information.

You are welcome to put this on the official wiki (which also serves as the place for the API documentation), so application developers can get the data they need in a parsable format.

veggies.2178:

As a proud owner of 11 “mule” alts out of 35 character slots, i like the api changes, but one thing that anoyed me is the lack of api for character inventory.

I had to create a lot alts to separate materials ex “axyd ore, axyd bloodstoner, axyd fluffer” and would love to see something done about it like for example ?accountid=1234?altname=axyd%20ore?invtype=bags (options are bank or character bags) and that would query out item item id & quantity for all bags equipped.

You mentioned bank storage and think thats cool but the one we hoarders need the most is to export mules presonal inventories.

Id also be happy if we could have like 100 bank tabs cause 7 is way too little….but thats another forum

Lawton Campbell.8517:

As a proud owner of 11 “mule” alts out of 35 character slots, i like the api changes, but one thing that anoyed me is the lack of api for character inventory.

We’re planning to eventually expose character inventories via the /v2/characters endpoint (and the account bank via /v2/account) so that someone can write a webapp to locate where you put that extra stack of Superior Sigils of Wrath or Lemongrass Poultry Soup. I’ll post a link to the Github PR once I’ve got the endpoint proposal writeup finished.

veggies.2178:

As a proud owner of 11 “mule” alts out of 35 character slots, i like the api changes, but one thing that anoyed me is the lack of api for character inventory.

We’re planning to eventually expose character inventories via the /v2/characters endpoint (and the account bank via /v2/account) so that someone can write a webapp to locate where you put that extra stack of Superior Sigils of Wrath or Lemongrass Poultry Soup. I’ll post a link to the Github PR once I’ve got the endpoint proposal writeup finished.

Thank you very much.
Been waiting for it since….1 month after launch lol

Lawton Campbell.8517:

Guild management and especially member management can be a big problem in larger guilds. Having Roster and Roster History exposed would be a huge thing.

This is definitely on my todo list, but I don’t yet have any designs for the endpoints. One of my guild leaders exports the influence log by hand to a spreadsheet so he can compute and graph various engagement metrics — that’s really something that should be automatable.

Remfin.4892:

Just to be clear, when we keep talking about authentication and authentication APIs, what scenarios are intended to be supported?

  • “User” APIs (apps calling APIs)
  • “Server” APIs (servers/websites calling APIs On-Behalf-Of)
  • External authentication (ala OpenID and such) (being able to get and verify a token that ANet says you’re “X”)

icepotato.6037:

As a proud owner of 11 “mule” alts out of 35 character slots, i like the api changes, but one thing that anoyed me is the lack of api for character inventory.

We’re planning to eventually expose character inventories via the /v2/characters endpoint (and the account bank via /v2/account) so that someone can write a webapp to locate where you put that extra stack of Superior Sigils of Wrath or Lemongrass Poultry Soup. I’ll post a link to the Github PR once I’ve got the endpoint proposal writeup finished.

this would be great! another use case for this would be something like a crafting guide website that can peek into your inventory to accurately kitten if it’s cheaper to buy something or make it yourself.

Sytherek.7689:

After reading this thread, I’m concerned about privacy.

Will the API allow anyone to investigate, say, anyone else’s backpack or storage?

Are we going to have to worry about gear-check apps?

Pat Cavit.9234:

After reading this thread, I’m concerned about privacy.

Will the API allow anyone to investigate, say, anyone else’s backpack or storage?

Are we going to have to worry about gear-check apps?

No, you will have to give applications access to your data.

Remfin.4892:

After reading this thread, I’m concerned about privacy.

Will the API allow anyone to investigate, say, anyone else’s backpack or storage?

Are we going to have to worry about gear-check apps?

*Assuming Server APIs are supported

Authenticated in this case means by the person who’s information is being displayed.

Can you look up a random person’s gear? No

Could a guild leader force you to expose your gear to him via a website, or a group of random people kick you if don’t put your gear on a publicly accessible website or its on there and they don’t like it? Yes. Don’t associate with those people (and maybe ANet will make up a rule around that kind of behavior).

Sytherek.7689:

After reading this thread, I’m concerned about privacy.

Will the API allow anyone to investigate, say, anyone else’s backpack or storage?

Are we going to have to worry about gear-check apps?

No, you will have to give applications access to your data.

Thanks for the prompt reply! I really do appreciate it…

Lawton Campbell.8517:

Just to be clear, when we keep talking about authentication and authentication APIs, what scenarios are intended to be supported?

  • “User” APIs (apps calling APIs)
  • “Server” APIs (servers/websites calling APIs On-Behalf-Of)
  • External authentication (ala OpenID and such) (being able to get and verify a token that ANet says you’re “X”)

The authenticated APIs will use OAuth2, which is best described by the second (servers/websites calling APIs On-Behalf-Of). You must explicitly grant a server access to specific portions of your account for your data to be disclosed. Servers/API consumers cannot access any API which requires authentication without the explicit consent of the user whose data is exposed.

While technically OAuth2 isn’t meant to be used for authentication, the /v2/account endpoint will effectively provide external authentication so you can restrict e.g., guild websites to only people who are actually in the guild without relying wholly on manual in-game checks.

Drant.5902:

Can we get the current list of daily achievements, so we can mark for players what world boss or WvW capture is for today.

Also, the events.json could be revived for megaserver instances via /ip command. So people who do temples or daily zone events don’t have to wait or spam map chat asking for active events.

Lawton Campbell.8517:

One API endpoint I’d like to see would provide access to historical trading post data — for example, to get the data to produce a graph similar to those on gw2spidy, gw2tp, etc.

Doing this currently requires constructing an external database and scraping the APIs regularly to populate it, and data from before the scrapes started is never accessible.

Before putting up a proposal for the endpoint parameters and response format, would something like this be possible? I.e., does ArenaNet store a detailed history of trading point data? Would the sheer amount of data that would potentially be pushed through their servers be problematic?

And thanks for starting this Pat — the APIs are one of the coolest things about this game for people like me

Lawton’s got a proposal for a user-specific TP transactions history endpoint he should be putting up as a PR. We need to get authenticated APIs up & stable before that API can become a reality though.

Here’s the PR for /v2/commerce/transactions, which would allow users to delegate access to their trading post transaction history.

zerorogue.9410:

The most wanted thing for me has always been retrieving character/account data through the api.

Such things as.
-Retrieving their bank/inventories on their characters.
-Retrieving Build data(Traits, equipment,skills)
-Retrieving their wallet data.
-Retrieving their buy/sell orders on BLT.
-Retrieving their BLT Drop box.
-Generating avatar Icons (The login screen Icon of the character.)
-Crafting levels and unlocked recipes.
-Wardrobe unlocks.

On the matter of actual editing of character/game data through the API I would rather not have it. This is for the fact of two things. First is the obvious bot issue. Second would be the fact players would be using third party programs rather than just playing the game.

Lawton Campbell.8517:

On the matter of actual editing of character/game data through the API I would rather not have it.

Don’t worry, it’s technically infeasible for us to edit game data. We only have a read-only copy (which is potentially ~5 minutes out-of-date) due to the nature of our architecture.

Bugabuga.9721:

Is it possible/reasonable to ask for expanded wvw match API?

Such as have RI counter being present?
i.e.

{ 
   "id": 32, 
   "owner": "Red", 
   "owner_guild": "277CCE76-6254-4CF2-8A2D-15A30B7110BD", 
   "RI": "01:45" 
}
Or objective taking time?

Also for guild endpoint (guild_details) to have currently running guild buffs/upgrades?


 {
   "guild_id": "75FD83CF-0C45-4834-BC4C-097F93A487AF",
   "guild_name": "Veterans Of Lions Arch",
   "tag": "LA",
   "emblem": {
     "background_id": 27,
     "foreground_id": 114,
     "flags": [],
     "background_color_id": 11,
     "foreground_primary_color_id": 584,
     "foreground_secondary_color_id": 64
   },
    "upgrades": [{
      "id": "bearLope",
      "type": "guildRush",
      "expirationTime": "2015-02-19 18:55:00"
    }]
 }

Guild-related buffs could either be public or private and only visible to authenticated user (and, of course, can be split out into separate uuid-driven end-point, with ID being numeric)

Adelas.6598:

We’re planning to eventually expose character inventories via the /v2/characters endpoint (and the account bank via /v2/account) so that someone can write a webapp to locate where you put that extra stack of Superior Sigils of Wrath or Lemongrass Poultry Soup.

sobs with joy

Sounds like it’s time to bake some more cookies…

Anyway, ZeroRogue has really nailed it for me, personally, with his list of things like bank and inventory items – the only thing I don’t see in his list is achievements. Having a website or phone app that could help me keep track of achievements would be AMAZING.

1. general account achievements
2. personal story and living story completion
3. map completion – being able to check an app to see which end of Lornar’s I need on my norn vs. what I need on my charr would allow me to coordinate mapping with my friends. Wow, would that be great.

In case it’s not obvious, I’m not a programmer/dev/whatnot, but if you made this particular information available to people who ARE, so they could write sites and apps for us, I would just melt with happiness.

famfamfam.9137:

I’m interested in plans for versioning and compat.

In terms of making PR requests for format changes to existing endpoints, do you have any plans for how versioning will be handled to not-break backwards compatibility for existing clients? What are your existing thoughts on this, and do you think its possible/reasonable to do while also adding the huge list of functional things people want from the API?

Would it be best to make a PR proposal for the ability to specify the specific endpoint version you want to use per-request and changes to?

(Typed out a longer post but the forums swallowed it)

Pat Cavit.9234:

I’m interested in plans for versioning and compat.

In terms of making PR requests for format changes to existing endpoints, do you have any plans for how versioning will be handled to not-break backwards compatibility for existing clients? What are your existing thoughts on this, and do you think its possible/reasonable to do while also adding the huge list of functional things people want from the API?

Would it be best to make a PR proposal for the ability to specify the specific endpoint version you want to use per-request and changes to?

(Typed out a longer post but the forums swallowed it)

This is a longer-term question, we don’t have a complete answer yet. I’d like to move to that model after we’ve plumbed more of the data through, I just don’t know how we’d support that sanely within our codebase. I also haven’t seen any implementations of a model like that in an API I’ve used/investigated so I don’t know what sort of best practices we should follow.

I’d write up your proposal in a forum post or gist, it’s too long-term of an idea for a PR to be very useful right now. After we’ve gotten over the hump of exposing most of the useful/interesting data available I’d like to circle back around on a consistency pass that would potentially include a more flexible versioning story.

In terms of the current /v2 API, once we ship the API it won’t have fields deleted or renamed. We may add fields as more data becomes available.

zerorogue.9410:

Anyway, ZeroRogue has really nailed it for me, personally, with his list of things like bank and inventory items – the only thing I don’t see in his list is achievements. Having a website or phone app that could help me keep track of achievements would be AMAZING.

I had a few paragraphs written with everything I would hope to have with an account API including achievements, but I shortened it down so it was not so “wall of texty”

I would hope to have nearly everything in game viewable in API form, but my #1 hope is to get synergy from site to game so you can plug your data into a site and get personalized guides.

On that point I do hope we have a public and a private space for accounts. Public is basic data on the account, (Character names,Professions, levels, Status, Map currently on, Achievement points, hours played?) Private is everything else and requires authentication.

The private data should be kept secure so players who like their privacy are private.

For instance a system similar to the two step authentication that we have to login. Where a player generates access keys that they give to sites that are valid only for one ip. (although this would be an issue for anyone with a roaming ip. Perhapses make an access account?)

smiley.1438:

I’ve already proposed some json structure changes for the WvW APIs, so i’m gonna link these here for now – i’ll create some PR tomorrow.

matches.json https://gist.github.com/codemasher/8876102#file-matches3-json
match_details.json https://gist.github.com/codemasher/8894954
objectives.json https://gist.github.com/codemasher/bac2b4f87e7af128087e#file-gw2_objectives-json
(more to follow)

Thanks for the new floors.json, thats basically what i’ve proposed earlier

Sol Solus.3167:

The trading post APIs only accept IDs, so it would make sense to have an item name search API to get that ID. Right now the only way to implement name search is to maintain your own database, which is burdensome for non-website apps.

Preferably, it would allow type, rarity, etc. filters via parameters.

Lawton Campbell.8517:

I’ve already proposed some json structure changes for the WvW APIs, so i’m gonna link these here for now – i’ll create some PR tomorrow.

matches.json https://gist.github.com/codemasher/8876102#file-matches3-json
match_details.json https://gist.github.com/codemasher/8894954
objectives.json https://gist.github.com/codemasher/bac2b4f87e7af128087e#file-gw2_objectives-json
(more to follow)

Ooh, those look shiny. In addition to fixing up the response format, I definitely do want to get the objective flip times in there, though I think that’ll take some more involved backend changes.

The trading post APIs only accept IDs, so it would make sense to have an item name search API to get that ID. Right now the only way to implement name search is to maintain your own database, which is burdensome for non-website apps.

Preferably, it would allow type, rarity, etc. filters via parameters.

Actual search endpoints is definitely something I’ve been looking into. The way we pull content data right now is to basically load stuff from the dat file — which is designed for semi-random access and doesn’t really yield itself to indexing. So I’m trying to pull all the data into a more normalized format so we can load it into search indexes and index all the things (not just items/recipes, but also future endpoints like skills and maps and whatnot). Still a ways from being production ready though ;_;

famfamfam.9137:

I’m interested in plans for versioning and compat…

I’d write up your proposal in a forum post or gist, it’s too long-term of an idea for a PR to be very useful right now.

If I get a chance I’ll gist a story and proposal.

After we’ve gotten over the hump of exposing most of the useful/interesting data available I’d like to circle back around on a consistency pass that would potentially include a more flexible versioning story.

Understandable and preferred. Looking forward to auth!

Bugabuga.9721:

I’ve already proposed some json structure changes for the WvW APIs, so i’m gonna link these here for now – i’ll create some PR tomorrow.

matches.json https://gist.github.com/codemasher/8876102#file-matches3-json
match_details.json https://gist.github.com/codemasher/8894954
objectives.json https://gist.github.com/codemasher/bac2b4f87e7af128087e#file-gw2_objectives-json
(more to follow)

Thanks for the new floors.json, thats basically what i’ve proposed earlier

That makes me wonder — perhaps there should be “abbreviated” mode of endpoint? (and further compact it like this: https://gist.github.com/msmolev/c22210d53d10a4edd233 ) if volume of data transmitted is causing problems.

What will be the acceptable rate of requests for v2 API?

Pat Cavit.9234:

Thanks for the new floors.json, thats basically what i’ve proposed earlier

No problem! Thanks for all your suggestions, they were really useful.

I’ve already proposed some json structure changes for the WvW APIs, so i’m gonna link these here for now – i’ll create some PR tomorrow.

matches.json https://gist.github.com/codemasher/8876102#file-matches3-json
match_details.json https://gist.github.com/codemasher/8894954
objectives.json https://gist.github.com/codemasher/bac2b4f87e7af128087e#file-gw2_objectives-json
(more to follow)

Thanks for the new floors.json, thats basically what i’ve proposed earlier

That makes me wonder — perhaps there should be “abbreviated” mode of endpoint? (and further compact it like this: https://gist.github.com/msmolev/c22210d53d10a4edd233 ) if volume of data transmitted is causing problems.

Unless there are amazing savings from doing so either on our end or the consumer’s end I’m not particularly interested in supporting two output styles for a particular endpoint. That just sounds like more code to write/debug/write tests for/maintain. I decided to investigate what the actual over-the-wire costs are for /v1/wvw/matches.json.

We gzip all responses for clients that support it (almost everyone) and the current /v1/wvw/matches.json output while verbose isn’t crazy. It’s 2.6KB uncompressed, but over the wire it’s only 380 bytes. The examples matches2.json starts out significantly smaller at ~700 bytes, and after gzip it’s down to ~325 bytes. So overall savings over the original file of 55 bytes.

I’m definitely not going to build & maintain two code paths to save 55 bytes over the wire, sorry.

What will be the acceptable rate of requests for v2 API?

All of our API responses are cached for some period of time, so right now we aren’t enforcing any particular limits. It would be simple for us to rate limit endpoints in the future but we’re going into this in good faith that people won’t abuse it. Also our API frontends are pretty robust and giving them a good workout from time to time is nothing for us to panic about.

If you start noticing slowness/spotty responses though do let us know!

aRestless.6213:

Flip times for WvW would be great! Would solve quite a few of my problems with that endpoint.

DeviantShark.6548:

Okay, this is actually the first time I post to a cdi, so forgive me if i made everything wrong. I just believe I speak for others with what I ’am about to say:

Guild-API
With the possibility of authentication there ought to be some guild-roster-api, but i don’t know how this should be implemented. Obviously there should be a setting in the ingame privileges tab like “API-Access” which grants those rights to a specivic guild group.
But then again, since this would be an ingame change this might not fit in here.

Now why would I love this?
Leading a somewhat medium sized guild (100+) it is getting tricky remembering all names as well as the invite date, and the date of first representation. Also this would allow to show some statistics about how much of his online time the person is actually representing said guild. Also this could help figuring out which content the guild is mostly doing. If 60% of people are almost exclusively bashing doors in the borderlands and only 2% are doing fractals every now and then, the next contest probably shouldn’t be fractals, if you know what I mean.

Statistics can help a lot achieving balance for the players.

Ravenmoon.5318:

I would like to see improved Guild API which would help make better community websites with stuff like

  • Members (Representing/Not Representing/Total)
  • Member Character Names
  • Upgrades Queue
  • Some sort of a log for completed guild missions
  • Guild bank? (shouldn’t be an issue to make it public data :O )
  • And maybe an extension for the upcoming expack, like .. does the guild have a hall, how does it look like
  • GvG History
  • Upcoming GvG Matches

I’d like to see people being able to extract pictures of their toons, or at least avatars.

I would love to see steps being taken to get back the Events API, including a way for people to PICK the server in-game (i know, i know this isn’t exactly an API request, but I’m sure you guys can bring more attention/weight to this detail than a simple user like me)

Also sPvP could see some love, by having an API endpoint interfacing with the leaderboards, and maybe even a build data (not necessary, I do see how that can be used to gain unfair advantage, knowing your enemy and all). The basics could be covered, like rank, and some achievements data, like players killed, points made and stuff like that.

Lumiere.4609:

Some PvP API would be fantastic. I think it would be really cool if we could potentially create something like dotabuff but it just does not seem possible at the moment. Being able to access things like match details (kills, deaths, points, builds players were running) would be fantastic not only for match sites but also for things like post game breakdowns in tournaments.

(snip)
Also sPvP could see some love, by having an API endpoint interfacing with the leaderboards, and maybe even a build data (not necessary, I do see how that can be used to gain unfair advantage, knowing your enemy and all). The basics could be covered, like rank, and some achievements data, like players killed, points made and stuff like that.

https://forum-en.guildwars2.com/forum/community/api/Proposal-Structured-PvP-API/first#post4802052

I’ll write a PR this weekend…

smiley.1438:

Actual search endpoints is definitely something I’ve been looking into. The way we pull content data right now is to basically load stuff from the dat file — which is designed for semi-random access and doesn’t really yield itself to indexing. So I’m trying to pull all the data into a more normalized format so we can load it into search indexes and index all the things (not just items/recipes, but also future endpoints like skills and maps and whatnot). Still a ways from being production ready though ;_;

Pretty please with sugar on top! Especially a search endpoint for the maps API (POIs and stuff) would be extremely helpful to create maps for the Wikis.

So please: (couldn’t resist)

quenoz.3859:

i would be really excited about a possibility to have guild chat outside of the game too, maybe somewhat like twitch allows to connect to their irc: http://help.twitch.tv/customer/en/portal/articles/1302780-twitch-irc

Light.7493:

I would like to suggest implementation of Zone chat API. It should follow the footsteps of twitter API in terms of structure. Something like:
GET https://blahblah/chat?limit=100&zone=1

{
zone:1,
messages: [
{
“name”: “blah”,
“message”: “blahblah”,
“time”:“00:00:00 UTC”
},

{
“name”: “blah”,
“message”: “blahblah”,
“time”:“00:00:00 UTC”
}
]
}

dlonie.6547:

Either John Smith has his own server with all (I mean ALL) the data, or you have it somewhere in some form of historic tables. That’s just a wild guess.

Querying it is neither fast nor scalable, so it’s very unlikely that we’ll be able to provide access to anything beyond what you can see via the in-game UI. I think the current cutoff for the transaction history is three months, but might be mistaken about that.

Would it be feasible to reduce the data to improve the database performance?

The query could return statistics for a time interval. For each item:

{
“id”: xxx,
“start_time”: xxx,
“end_time”: xxx,
“buy_price” : { “min”: xxx, “max”: xxx, “mean”: xxx },
“sell_price” : { “min”: xxx, “max”: xxx, “mean”: xxx },
“demand” : { “min”: xxx, “max”: xxx, “mean”: xxx },
“supply” : { “min”: xxx, “max”: xxx, “mean”: xxx },
“bought”: xxx,
“sold”: xxx
}

The further back in time, the coarser the granularity, e.g. for the last week/month the statistics could be stored at hourly intervals, for 1-12 months back, store at the day level, and for 12+ months back, store a weekly summary.

This would still allow users to plot a representative history, and provide enough detail for analyzing recent trends in the market history, without having to serve every individual transaction.

This would require a periodic sweep through the data to condense the summaries as they move into different level-of-detail windows, but would greatly reduce the amount of data.

Khisanth.2948:

All I want for now is just 3 things:

  • Some sort of authentication, so the API can get permission to get info about an account and its characters.
  • A way to get the info of all copies of a map, and the info of a particular copy of a map. Combined with the authentication and the events API, it’ll be able to tell you the event of the particular copy of the map the current character of an account is in just like before megaserver.
  • Also combined with the authentication, a way to pull contact lists, and be able to pull the locations of the reciprocal friends of that account if they are in the same copy of the map.

Is it possible to take this a step further?

Be able to get a list of what events are active, or the timers on the inactive events for all instances of a given map?

IE, if I wanted to do Balthazar but I’m in Queensdale. Being able to see if there are any instances in progress or about to start would be nice. This would make it easier for people to organize on specific maps to do these events.

The inactive timer thing is probably not possible but we should at least be able to get back to how the events API worked before megaserver.

There is no way to select which instance you end up so seeing which instances have what events doesn’t seem very useful.

Lawton Campbell.8517:

With the possibility of authentication there ought to be some guild-roster-api, but i don’t know how this should be implemented. Obviously there should be a setting in the ingame privileges tab like “API-Access” which grants those rights to a specivic guild group.

Probably not going to be an in-game opt-in for this. Anyone in the guild can already see the roster in-game, so it doesn’t make sense to hide the roster from them out-of-game.

i would be really excited about a possibility to have guild chat outside of the game too, maybe somewhat like twitch allows to connect to their irc: http://help.twitch.tv/customer/en/portal/articles/1302780-twitch-irc

Out-of-game guild chat is definitely something I want to have, but we haven’t really settled on a protocol for it yet. XMPP, IRC and “something custom with HTTP+SSE” have all been tossed around as potentials but it’s not immediately clear which is most advantageous to implement. As far as interoperability with existing clients, IRC’s probably the winner (though it’s a horrible mess of a protocol).

Rising Dusk.2408:

So let’s say I want to “opt in” to an app or overlay that allows other players to perform a gear check on me in dungeon groups. How would I do that? Would I have to use the app? Or would there be a user preference in-game (disabled by default) that shares my information for others to pull from the API?

wwwes.1398:

I would like to throw my vote towards XMPP for group chats.

Lawton Campbell.8517:

So let’s say I want to “opt in” to an app or overlay that allows other players to perform a gear check on me in dungeon groups. How would I do that? Would I have to use the app? Or would there be a user preference in-game (disabled by default) that shares my information for others to pull from the API?

You’d go to the app’s webpage, which would redirect you to the official sign-ins. After signing in, you’d be presented with an authorization prompt telling you what permissions the app is requesting. Clicking a “accept” button would send you back to the app and give the app a token they can use to make authenticated API requests on your behalf.

So, an example app, “pingyourgear.com”, might allow you to list your party members by name. You could them send them to the app — they’d log in and grant the app access to view their equipment. The app would pull their equipment and update it on your screen. The app could additionally save authentication tokens (with the user’s permission) so they’d only have to opt-in once — so any party members you add who’ve already used the app could have their current gear appear immediately on your UI.

coldwaterq.6258:

Something I would like to see added to the items api is for the vendors that the item can be purchased from to be included, along with the price those vendors charge. Alternatively the lowest price charged by a vendor would also be nice.

ClockworkUnltd.2690:

For the authenticated api, I would like to request adding the time a particular skill was last used.

Lawton Campbell.8517:

Something I would like to see added to the items api is for the vendors that the item can be purchased from to be included, along with the price those vendors charge. Alternatively the lowest price charged by a vendor would also be nice.

This is on my list, but it’s pretty far down as it is actually quite difficult to determine which vendors are (or have been) player-accessible, and under what conditions they’ll actually sell their items. Some additional discussion in this thread.

For the authenticated api, I would like to request adding the time a particular skill was last used.

This is more-or-less infeasible. The data we have access to is always between 1 and 5 minutes stale. The stream of data that could meaningfully contain skill usages (e.g., the raw logs) may be even more out-of-date.

Basically, none of the APIs actually talk to game servers and are heavily cached, so real-time info isn’t going to happen.

quenoz.3859:

Out-of-game guild chat is definitely something I want to have

that is great to hear!

Ravenmoon.5318:

With the possibility of authentication there ought to be some guild-roster-api, but i don’t know how this should be implemented. Obviously there should be a setting in the ingame privileges tab like “API-Access” which grants those rights to a specivic guild group.

Probably not going to be an in-game opt-in for this. Anyone in the guild can already see the roster in-game, so it doesn’t make sense to hide the roster from them out-of-game.

i would be really excited about a possibility to have guild chat outside of the game too, maybe somewhat like twitch allows to connect to their irc: http://help.twitch.tv/customer/en/portal/articles/1302780-twitch-irc

Out-of-game guild chat is definitely something I want to have, but we haven’t really settled on a protocol for it yet. XMPP, IRC and “something custom with HTTP+SSE” have all been tossed around as potentials but it’s not immediately clear which is most advantageous to implement. As far as interoperability with existing clients, IRC’s probably the winner (though it’s a horrible mess of a protocol).

Go with your own protocol. People are doing chatrooms with Node.js and socket.io ever since it released. WebSockets is a nice TCP/IP wrapper and is supported on all major browsers. Its easy to write against it so I can see client apps being developed around it too. If you limit the messages to 128 bytes, you won’t have to ever implement the protocol chunking, which saves you loads of work.

IRC is older than me (I’m 24 years old), it is time to let it go xD

WebSockets usability info: http://caniuse.com/#feat=websockets

dlonie.6547:

IRC is older than me (I’m 24 years old), it is time to let it go xD

This is actually an advantage to using IRC (or another off-the-shelf technology) — existing chat clients already understand it and third party apps can use existing libraries since the protocol has had time to gain acceptance.

IRC has some cobwebs for sure, but everything understands it

Not to mention that it will only require them to develop an interface layer between GW2 chat and IRC, rather than build (and test and maintain) their own protocol/server implementation.

Gah. Now I sound like my boss does when I get carried away, wanting to rewrite everything myself. kitten I hate the real world >.<

Arcan Soulstorm.4356:

I’d like to see a flag for waypoints in keeps and SMC in WvW as they are visble to every player by looking on the map.

mahri.8410:

I would like the API to provide location coordonates of players. If I would be able to see my guildmates location on Tyria map in a web app, there would be more collaboration.

Also, another suggestion for the API is 3D asset streaming. Currently, only 2D assets could be displayed, such as items. What I suggest here is 3D asset streaming.

This could be done in multiple ways . I’ve linked here a PDF called 3D mesh streaming based on predictive modelling :
http://thescipub.com/abstract/10.3844/jcssp.2012.1123.1133 (click read full pdf)

What I suggest is something like this: Let’s say we have a 3D model of a lion statue from the submerged Lion Arch. That statue is isolated, and more photos are taken around it, at different angles and zoom levels. The photos are stored on the server, associated with the respective asset. API users could request various photos. On the app side, the images are combined in spherical shapes ( think of Google Street View), with different sizes, based on zoom. So, that asset could be viewed in 3D inside the app.
I would suggest png format streaming, because it supports transparency. This could also be done for animations and particle effects.

ClockworkUnltd.2690:

I would like the API to provide location coordonates of players. If I would be able to see my guildmates location on Tyria map in a web app, there would be more collaboration.

I believe this can be done with the mumble API. It includes your coordinates, plus other information (such as the direction you are facing, etc). Others have created apps where you can track your own movement. Building on this, you should be able to centralize this information and display it to any users you wish to convey the information to.

Lawton Campbell.8517:

IRC is older than me (I’m 24 years old), it is time to let it go xD

This is actually an advantage to using IRC (or another off-the-shelf technology) — existing chat clients already understand it and third party apps can use existing libraries since the protocol has had time to gain acceptance.

IRC has some cobwebs for sure, but everything understands it

I’m in the IRC boat myself, but arguably XMPP shares the same “doesn’t need a custom client” properties. Also, calling IRC cobwebby is a bit of an understatement — the protocol is riddled with all kinds of undocumented extensions and it really baffles me that clients are even capable of communicating with the wide range of implementations that they do.

The main issue with IRC/XMPP is that it would require a bridge to use within a browser. We need to internally figure out what our most common use-cases for a chat endpoint will be, I think.

There’s also an authentication issue with IRC/XMPP that I’m not sure how best to handle (e.g., OAuth2 isn’t really going to work for it), but eh.

I would like the API to provide location coordonates of players. If I would be able to see my guildmates location on Tyria map in a web app, there would be more collaboration.

This probably won’t be technically feasible. We don’t have real-time access to character data (it can be up to 5 minutes stale).

Also, another suggestion for the API is 3D asset streaming. Currently, only 2D assets could be displayed, such as items. What I suggest here is 3D asset streaming.

I’d prefer to just provide the 3D models and textures in a common format, then let the application render them directly with e.g., WebGL. Makes everything a bit less complicated.

Whether or not that’s something we can provide is a question that’s above my pay grade :P

As far as pre-rendered stuff goes, I really really want to provide character portraits though. There are some outstanding difficult-to-solve issues with rendering on servers that we’d have to sort out first though, so it’s probably not going to happen for a long while.

aRestless.6213:

Whether or not that’s something we can provide is a question that’s above my pay grade :P

Even if you could decide that – you shouldn’t do it. There are already copy-paste low budget games out there that simply copy the Guild Wars 2 UI. Throwing out models and textures in a convenient easy-to-use format would only extend this content theft to all kinds of assets.

Edit, to avoid double post:

I would like the API to provide location coordonates of players. If I would be able to see my guildmates location on Tyria map in a web app, there would be more collaboration.

I believe this can be done with the mumble API.

Yep. Markers can already do that, although it would display your guild members on the ingame map instead of a web app. However, as soon as the current update is finished (features, performance, stability… ugh, I hate JavaScript) I’ll get in touch with the creators of various map-rendering projects to achieve interoperability. I’ll probably be able to provide a simple JavaScript wrapper that handles communication with a share server and spits out information about player positions and so on.

Rising Dusk.2408:

You’d go to the app’s webpage, which would redirect you to the official sign-ins. After signing in, you’d be presented with an authorization prompt telling you what permissions the app is requesting. Clicking a “accept” button would send you back to the app and give the app a token they can use to make authenticated API requests on your behalf.

So, an example app, “pingyourgear.com”, might allow you to list your party members by name. You could them send them to the app — they’d log in and grant the app access to view their equipment. The app would pull their equipment and update it on your screen. The app could additionally save authentication tokens (with the user’s permission) so they’d only have to opt-in once — so any party members you add who’ve already used the app could have their current gear appear immediately on your UI.

Makes perfect sense. Thanks so much for the very thorough walkthrough of the typical usage model!

McWolfy.5924:

Befor release anet promised mobile apps. I think its a great opportunity to rise the gaming experience. Chat, tp buy-sell, something SAB kind of game (or SAB itself) etc…
Now we only have event timers, tp price check and wiki
I realy want to log in from my mobile and enjoy a part of the game

Tub.4560:

Also, calling IRC cobwebby is a bit of an understatement — the protocol is riddled with all kinds of undocumented extensions and it really baffles me that clients are even capable of communicating with the wide range of implementations that they do.

eh.. the extensions are either channel modes/user modes which a client is allowed to ignore, or arcane protocols for server-to-server communication. A client implementing all of RFC 1459 must work with all IRC servers, and a server implementing nothing but RFC 1459 must work with all clients. Implementing just some core functionality would be sufficient for everything.

That being said, I dislike IRC and XMPP because they’re unencrypted (or only optionally encrypted). I really don’t want external apps to start sending my guild chat unencrypted over the wire. I’m aware that all ingame-chat is fully logged by arenanet and thus should never be used for confidential information, but that doesn’t mean it should be readable by just anyone.

I also insist that it is always possible to see who is logged into the chat, including API logins. If someone decides to run a 24/7 logging-bot, I want to know.

As for feature requests: Eventually, I’d like to be able to export my character with weapon, armor and dyes in a pre-selected pose as a 3d model. You know, 3d printers. Not sure if that’s feasible (doesn’t the posing rely on vertex shaders, which are difficult to emulate on CPU?), but it’d be cool.

munkiman.3068:

This probably won’t be technically feasible. We don’t have real-time access to character data (it can be up to 5 minutes stale).

I’m confused, this is possible now with mumble tracking, can you not write an extension that utilizes that code? This seems pretty straight forward to me and something mentioned before the game launched.

Teranas.6150:

I’m confused, this is possible now with mumble tracking, can you not write an extension that utilizes that code? This seems pretty straight forward to me and something mentioned before the game launched.

I suppose mumble retrieves its data directly from client side in real time meanwhile the API retrieves its data from pre cached databases of the server. This data will be pretty fast outdated when you get them from the API.

Two very different mechanisms.

Pat Cavit.9234:

Befor release anet promised mobile apps. I think its a great opportunity to rise the gaming experience. Chat, tp buy-sell, something SAB kind of game (or SAB itself) etc…
Now we only have event timers, tp price check and wiki
I realy want to log in from my mobile and enjoy a part of the game

That team hasn’t existed for years (I know, I was on it) it wasn’t going to ship anything unless we cut lots of stuff. The “Extended Experience” was doomed by a number of factors that aren’t worth going into, but I wouldn’t hold your breath for it to return in that form.

Lawton Campbell.8517:

I’m confused, this is possible now with mumble tracking, can you not write an extension that utilizes that code? This seems pretty straight forward to me and something mentioned before the game launched.

I suppose mumble retrieves its data directly from client side in real time meanwhile the API retrieves its data from pre cached databases of the server. This data will be pretty fast outdated when you get them from the API.

Two very different mechanisms.

Pretty much on the money.

Erunno.3295:

Is it possible to allow more than one value in the “lang”-parameter? Or “all” as possible value? This would allow to get more than one language with one request and would make these almost redundant requests required at the moment obsolete.

smiley.1438:

This would allow to get more than one language with one request and would make these almost redundant requests required at the moment obsolete.

This is what i’ve requested more than once, see also:

https://github.com/codemasher/api-cdi/commit/02fd35622ef844e3d8c2d7974e462c8478f6def2
https://github.com/codemasher/api-cdi/commit/c105219b42413e047ce0e985dca93a13910c5817

katz.8376:

Is it feasible to add swords popping on a WvW objective to the API?

Pat Cavit.9234:

Is it possible to allow more than one value in the “lang”-parameter? Or “all” as possible value? This would allow to get more than one language with one request and would make these almost redundant requests required at the moment obsolete.

Potentially, but it isn’t something we’ve spent much time looking at just yet.

It raises a lot of format questions for me as to what the actual response would look like. Would it be the regular, language-specific responses repeated n times (where n is the number of requested languages)? That’s going to be a huge response for some endpoints. There are other options but it requires us to write a bunch more code to support it by changing the responses we get (remember, the API frontend you talk to is a middle-man) and I don’t really think it’s worth it.

Why do you need multiple languages in a single response?

Erunno.3295:

Why do you need multiple languages in a single response?

I want to let the user search for items by different criterias. So my plan was to parse the data into a database and use indexes for the searches. To support several language i need to know the item names in theese languages. It is not a big problem to repeat the request and ignore everything except the names, but it would be easier to just fire one request and get everything I need.
Most of the data the apis provide doesn’t change very frequently, so imho it is feasible to cache it even without a database in the back.
The format smiley used in his pull-requests looks good to me. And if only one language is requested, it stays just like it is now.

P.S. There is a working work-around, so this is no high prio of course.

Pat Cavit.9234:

Why do you need multiple languages in a single response?

I want to let the user search for items by different criterias. So my plan was to parse the data into a database and use indexes for the searches. To support several language i need to know the item names in theese languages. It is not a big problem to repeat the request and ignore everything except the names, but it would be easier to just fire one request and get everything I need.
Most of the data the apis provide doesn’t change very frequently, so imho it is feasible to cache it even without a database in the back.
The format smiley used in his pull-requests looks good to me. And if only one language is requested, it stays just like it is now.

P.S. There is a working work-around, so this is no high prio of course.

Yeah, the problem I see with smiley’s PRs is that we have to write code for every endpoint to add comprehensions for the specific fields and transform them into objects. It’s not impossible of course, it’s just not a very good bang-for-our-buck change. We could work out a system to make marking up those fields easier or even diffing between responses from the backends but again, more important things atm.

We’ll keep it on the backburner, /v2 isn’t the end of the APIs & I’d like whatever comes next to offer more flexibility on things like this.

Teraphas.6210:

A request. I don’t do much work with api so i don’t know if this is possible. Could it either be made an api or an ingame option to track the storyline choices we have made?

say i am playing a second or third etc character of a race and i did the story so long ago that i don’t remember which missions i chose the first time. Could there be a way to see which paths we chose before. Nothing worse then either remembering wrong and having to restart. I had to reroll a charr because i forgot what legion i had made my first one and accidentally made my new one the same.

Yes i could (and had but lost)making notes as to which choices i make but with 8(and soon to be9) characters that is a lot of notes. and i could(and have) paused and consulted the awesome wiki but that takes a good bit of time and spoilers to read each mission to find out which you did before.

i saw talk here of being able to call up personal and account inventory stuff and was curious if the story and character creation choices were outside the realm of possibility.

especially if this was an ingame option(off by default probably) that showed up a little red text like when you know a recipe saying choice taken(maybe even with the number of times you have taken it) this would be great for us that are looking to explore all the various story paths and get a greater understanding of the Lore. especially since characters and events from certain arcs make their way into the LS.

Lawton Campbell.8517:

A request. I don’t do much work with api so i don’t know if this is possible. Could it either be made an api or an ingame option to track the storyline choices we have made?

say i am playing a second or third etc character of a race and i did the story so long ago that i don’t remember which missions i chose the first time. Could there be a way to see which paths we chose before. Nothing worse then either remembering wrong and having to restart. I had to reroll a charr because i forgot what legion i had made my first one and accidentally made my new one the same.

That’s already a thing. Check the “My Story” section of the “Story Journal” tab of the Hero Panel. The first entry has icons in the lower-right corner with tooltips indicating which character creation choices you made, and the other entries detail the choices you’ve made throughout your personal story.

It doesn’t give you the tl;dr “You pressed option 3” but it’s enough text to figure out which choice you chose.

Teraphas.6210:

yes but i mean as i am progressing the new character. I know the info is there but when i get to the end of the mission and need to make a choice i realize i have once again forgotten to write down what i have done before.

would just be nice to be able to turn it on ingame or use my phone or other monitor to quickly double check what pathes i have done with someone’s app that uses the api.

not hugely important but if the info is there would be nice to access it without having to jump on that charracter

Valento.9852:

Skills/traits – https://forum-en.guildwars2.com/forum/community/api/API-Suggestion-Skills-and-Traits/first#post4700324

Lawton Campbell.8517:

See the pull requests on the CDI repo.

Pat Cavit.9234:

I just merged the PR for the updates to /v2/floors (moving it under /v2/continents, adding lots of new selection functionality). Hoping to ship it next week sometime.

https://github.com/arenanet/api-cdi/pull/2

Kasima.8143:

I would like something that would allow voice chat software like Teamspeak, Mumble or Ventrilo to interface with the game (or vice versa) to display who is talking, as well as display text chat in the chat pannel. Overwolf is nice, but it’s still very buggy and interacting with it freezes the controls ingame.

anzenketh.3759:

I would like something that would allow voice chat software like Teamspeak, Mumble or Ventrilo to interface with the game (or vice versa) to display who is talking, as well as display text chat in the chat pannel. Overwolf is nice, but it’s still very buggy and interacting with it freezes the controls ingame.

There are other options available. This would not be associated with the Guild Wars 2 API.

The Geil.8605:

Timestamps for when an account is finishing an achievement would be pretty nice for creating timelines on an account. If we’ll get access to what loot people get, then a timestamp for those would also be appreciated.

aRestless.6213:

Due to the current Overwolf App Contest… is there a (rough) ETA or priorization for the upcoming API functionality? I could start implementing without the API up and running as long as I knew that the functionality would come within the time frame of the contest.

Lawton Campbell.8517:

Due to the current Overwolf App Contest… is there a (rough) ETA or priorization for the upcoming API functionality? I could start implementing without the API up and running as long as I knew that the functionality would come within the time frame of the contest.

My informal roadmap basically looks like this:

1. Get the OAuth2 application registration bits deployed.
(1.5. Pat’s /v2/continents additions.)
2. /v2/account/bank, /v2/account/materials.
3. /v2/commerce/transactions.
4. /v2/characters.

So, basically all authenticated endpoints which aren’t really useful within the scope of a desktop application. No timeline for those, but that’s the general order they’ll probably happen in. The other endpoints I’m working on still need a bunch of manual verification (looking at /v2/skills, there’s a lot of wonky stuff still coming out of my current implementation) or are otherwise still in a half-implemented proof-of-concept state.

Nabrok.9023:

Would /v2/characters expose everything that we currently see in the character select screen?

That would be …

  • Order most recently played
  • Level/Race/Class
  • Represented guild
  • % Map Completion
  • Last location
  • World (presumably for if a character is guesting? Not sure, I never really guest)

It would be useful to me to see which guilds an account belong to, having the guilds each character is representing may not give a full list but it would be something I could work with.

I’ve also had some ideas about how I could use the name of the character they are currently playing, and order of most recent play would achieve that.

Lawton Campbell.8517:

Would /v2/characters expose everything that we currently see in the character select screen?

That would be …

  • Order most recently played
  • Level/Race/Class
  • Represented guild
  • % Map Completion
  • Last location
  • World (presumably for if a character is guesting? Not sure, I never really guest)

It would be useful to me to see which guilds an account belong to, having the guilds each character is representing may not give a full list but it would be something I could work with.

I’ve also had some ideas about how I could use the name of the character they are currently playing, and order of most recent play would achieve that.

I haven’t written up the RFC for /v2/characters (should probably do that today so we can get some eyes on it), but briefly — no order, yes level/race/class, probably rep’d guild, no % map completion, no last location, no last guested. There’s a bunch of other stuff in there like current equipment, inventory items, etc., that’ll make it useful at first for some applications.

This doesn’t preclude those features from ever being added, they just aren’t attributes that are currently pulled out of the character data on our side yet (and it takes awhile to make and deploy changes to the code that parses character data, unfortunately).

EDIT: In addition to recently played, time played per character would be nice as well (also perhaps deaths, heh).

Alaska II.5819:

Is there anything that allows to pull outgoing damage? Like how much damage you are dealing to an enemy, everything (flat damage, condis) included. Possibly pull data from the combat data that’s already implemented as a chat option?

If not, that would be something nice to have.

Also, a way to pull transaction history (past buys and sells) from the trading post would be neat as well.

Bugabuga.9721:

Would /v2/characters expose everything that we currently see in the character select screen?

That would be …

  • Order most recently played
  • Level/Race/Class
  • Represented guild
  • % Map Completion
  • Last location
  • World (presumably for if a character is guesting? Not sure, I never really guest)

It would be useful to me to see which guilds an account belong to, having the guilds each character is representing may not give a full list but it would be something I could work with.

I’ve also had some ideas about how I could use the name of the character they are currently playing, and order of most recent play would achieve that.

I haven’t written up the RFC for /v2/characters (should probably do that today so we can get some eyes on it), but briefly — no order, yes level/race/class, probably rep’d guild, no % map completion, no last location, no last guested. There’s a bunch of other stuff in there like current equipment, inventory items, etc., that’ll make it useful at first for some applications.

This doesn’t preclude those features from ever being added, they just aren’t attributes that are currently pulled out of the character data on our side yet (and it takes awhile to make and deploy changes to the code that parses character data, unfortunately).

EDIT: In addition to recently played, time played per character would be nice as well (also perhaps deaths, heh).

For guild-related things probably better to keep both list of guilds and currently represented one (basically “which guilds character is in” and “right now represented blah”).

This way an overlay can show all guild activities at once (i.e. “Guild A is doing rush” “Guild B activated +5 transport buff” etc)

Dr Ishmael.9685:

Is there anything that allows to pull outgoing damage? Like how much damage you are dealing to an enemy, everything (flat damage, condis) included. Possibly pull data from the combat data that’s already implemented as a chat option?

The devs have stated repeatedly that they do not have access to real-time data. All of the API’s data is cached and usually at least 5 minutes old.

Nabrok.9023:

Is there anything that allows to pull outgoing damage? Like how much damage you are dealing to an enemy, everything (flat damage, condis) included. Possibly pull data from the combat data that’s already implemented as a chat option?

The devs have stated repeatedly that they do not have access to real-time data. All of the API’s data is cached and usually at least 5 minutes old.

I think this kind of thing (exporting chat/combat logs) should be handled directly by the client.

Either a real-time stream or a slash command to save the log.

Alaska II.5819:

Is there anything that allows to pull outgoing damage? Like how much damage you are dealing to an enemy, everything (flat damage, condis) included. Possibly pull data from the combat data that’s already implemented as a chat option?

The devs have stated repeatedly that they do not have access to real-time data. All of the API’s data is cached and usually at least 5 minutes old.

It didn’t have to be real time, just seeing the data from 5 minutes ago would be really helpful.

Lawton Campbell.8517:

For guild-related things probably better to keep both list of guilds and currently represented one (basically “which guilds character is in” and “right now represented blah”).

This way an overlay can show all guild activities at once (i.e. “Guild A is doing rush” “Guild B activated +5 transport buff” etc)

The currently represented one is stored per-character in the character data, so I was going to put it in /v2/characters rather than /v2/account.

I think this kind of thing (exporting chat/combat logs) should be handled directly by the client.

Either a real-time stream or a slash command to save the log.

Yeah, the client has a wealth of data available to it that we don’t; I’m not even sure how we’d go about exposing that (or what the process for getting it implemented would be). While it’s definitely something I’d like to expose, it’s realistically not going to be in any time soon :/

rodadams.5963:

Trying to keep this fairly concise:

https://github.com/arenanet/api-cdi/commit/c0aa094cebd52d1c9ce5040825be900e011ec3d9
Bank:

  • Transmuted to a new skin?
  • Is soulbound/account bound? (can change from base item)
  • If soulbound, to whom?
  • Uses left on harvesting tools/salvage kit.
  • If armor, is damaged/broken?

https://github.com/arenanet/api-cdi/commit/5fe9d1470f54e7fcbeb36c2c635217f55aa1ec7b
Commerce:

  • You have created timestamp, how about filled?
  • Any tracking for cancelled orders?
  • Have the gold/items been collected? (should I log in to grab my fat loot?)
  • Perhaps walk through what we’d see if we post a buy order for 250 ecto, 150 fill in various sized batches, and we then cancel the remaining order of 100.

https://github.com/arenanet/api-cdi/commit/7224da8e3c930f9635a902ce9f2592b34fb038b9
Skills:

  • Without information like cooldown, aftercast, damage, boons, conditions, target type, number of targets, range, etc. the utility of this endpoint will be very limited.
  • Will ‘categories’ be canonical in determining which traits can mutate it? I could see Phantasmal Berserker have several categories to support trait processing: “phantasm”, “illusion”, “greatsword”. Having the client build this list from “weapon_type” and a hierarchy of categories seems expensive and error prone. Exactly what does the Shrapnel trait apply to again?

How far down your list is /v2/account/wallet?

Will I have a server side portal to review and revoke security tokens?

Lawton Campbell.8517:

https://github.com/arenanet/api-cdi/commit/c0aa094cebd52d1c9ce5040825be900e011ec3d9
Bank:

  • Transmuted to a new skin?
  • Is soulbound/account bound? (can change from base item)
  • If soulbound, to whom?
  • Uses left on harvesting tools/salvage kit.
  • If armor, is damaged/broken?

IIRC, transmuted skins and charges show up (I’ll update the PR with the serializations). Binding and armor damage does not, and likely will not for the initial release. I’ll thread those through the pipeline and add them in later.

https://github.com/arenanet/api-cdi/commit/5fe9d1470f54e7fcbeb36c2c635217f55aa1ec7b
Commerce:

  • You have created timestamp, how about filled?
  • Any tracking for cancelled orders?
  • Have the gold/items been collected? (should I log in to grab my fat loot?)
  • Perhaps walk through what we’d see if we post a buy order for 250 ecto, 150 fill in various sized batches, and we then cancel the remaining order of 100.

Filled dates are in there, I’ll update the PR with the serialization. Cancelled orders are, IIRC, deleted wholly by the trade engine so there’s no way to get any record of them on my side (you’d have to track that on the application side). Pending gold/items work through a separate system that we currently have no insight into, so that’s not going to make it for the initial pass.

I’ll create the walkthrough you requested on Monday.

https://github.com/arenanet/api-cdi/commit/7224da8e3c930f9635a902ce9f2592b34fb038b9
Skills:

  • Without information like cooldown, aftercast, damage, boons, conditions, target type, number of targets, range, etc. the utility of this endpoint will be very limited.
  • Will ‘categories’ be canonical in determining which traits can mutate it? I could see Phantasmal Berserker have several categories to support trait processing: “phantasm”, “illusion”, “greatsword”. Having the client build this list from “weapon_type” and a hierarchy of categories seems expensive and error prone. Exactly what does the Shrapnel trait apply to again?

I’m intentionally omitting any skill attributes which can be modified by traits for exactly the reasons you mentioned — it needs to be clear exactly how traits modify skills. I have a couple of different serializations in mind, but want to hold off for a bit on posting them (too many other pots on the stove).

Rest assured, I want the returned data to be clear both ways — a skill should indicate that “trait 45 increases range to 1200” and the corresponding trait should indicate that it “modifies skills 14, 42 and 45”.

How far down your list is /v2/account/wallet?

Not terribly far.

Will I have a server side portal to review and revoke security tokens?

Yes.

Archomeda.6472:

Is it viable to have an API endpoint of the gem store itself? What I have in mind, is exposing the current available items with at least their prices, discount and deadline (maybe something more that I’m currently forgetting). This way people can provide automatic gold -> gem conversion costs for the gem store items (just an example use case I came up with at the moment).

Just to make myself clear: I’m not asking for providing a way to buy stuff with the API, just if providing the read-only data from the gem store is possible.

Pat Cavit.9234:

It’s possible, we’d have to discuss with the team responsible for the listings what filtering (if any) would need to happen to that data though. Worth adding to the backlog as a low-priority item, thanks!

smiley.1438:

This may be a little off topic, but https://hom.guildwars2.com/character/Lady%20Mimikry please?

Archomeda.6472:

It’s possible, we’d have to discuss with the team responsible for the listings what filtering (if any) would need to happen to that data though. Worth adding to the backlog as a low-priority item, thanks!

Cool ^^ thanks for the answer.

Lawton Campbell.8517:

Just finished an initial writeup of the /v2/characters endpoint.

Valento.9852:

Oh my, oh my! I didn’t know this CDI was happening in github! I’ve added a comment there.

Wilz.8461:

Hi,

I haven’t read everything in details about the new api but I don’t think this was mentioned.

  • Would it be possible to have the list of ingredients on items that can be crafted, even Mystic forge recipes like legendaries or exotic weapons (i.e infinite light, mjolnir, etc…) ?
    This information is on the wiki but not in the API.
  • afaik, the vendor price when selling the item is included in /v2/items but not the vendor price when buying the item (if buyable from the vendor)

Lawton Campbell.8517:

  • Would it be possible to have the list of ingredients on items that can be crafted, even Mystic forge recipes like legendaries or exotic weapons (i.e infinite light, mjolnir, etc…) ?
    This information is on the wiki but not in the API.

Not in the forseeable future. Refer to this thread.

  • afaik, the vendor price when selling the item is included in /v2/items but not the vendor price when buying the item (if buyable from the vendor)

There are some technical difficulties that prevent this from being feasible. More discussion in this thread.

Archomeda.6472:

I’ve got a small question, and I’m sure it has been brought up many times before, but I can’t find it at the moment.

Regarding the /v2/maps endpoint, is it possible to add a map_type entry for each map? With possible values like: city, dungeon, personal_story, living_story, instance, pvp, wvw. Or at least a way to separate instances from “normal” maps.

My reasoning is that, previously, with /v1/map_names.json, it would only return the major maps plus some random maps like the Crown Pavillion. This way I could “easily” identify which maps are actually maps and not instances. Granted, I was still missing the cities, but I could add those ids manually without much effort. However, at some day in the past (don’t know when), that endpoint got changed to include every map. So, my nice effort to get the major map boundaries is now a major disaster as I don’t know an automated way to separate maps by type other than this non-working workaround.

Also, now that I see this, I’ve got another question. Why are most instances located in Steamspur Mountains instead of their correct respective region? For example, map 1006 – Foefire Cleansing is clearly an instance from living story season 2 and is located in Plains of Ashford – Ascalon, yet it is tagged as Steamspur Mountains.

Also, using brackets in link titles doesn’t work on the forums apparently, had to resort to use dashes instead…

boomboompow.6185:

Would it be possible to add Daily Achievements to the API?

At the moment all Daily Achievements can be calculated as they are dependant on the day of the month but it would be great to have a RESTful API for this if/when it changes with future releases.

Edit: If this is coming with the /account endpoint then all the better

Tanis.5134:

I was hoping by now to see official proposals related to the upcoming changes to WvW. Objectives will all be wrong, and anyone using the tile service currently has no idea which continent and floor to use. It would be great if we could start consuming the v2 WvW endpoints prior to the release of HoT to ensure that everything is working well.

Valento.9852:

I think I’ve scared Lawton. No posts since my last post on skills CDI. ;_;

Lawton Campbell.8517:

Sorry sorry! Been busy working to implement everything!

Soon I’ll be busy deploying everything

Valento.9852:

Sorry sorry! Been busy working to implement everything!

Soon I’ll be busy deploying everything

No problem! I hope you have time to read the posts. Keep up the great work, sir!

dlonie.6547:

Lookin’ good guys! The transaction endpoint sounds fantastic

Teranas.6150:

I added a new proposal that may enables us to request players ingame mails.

Please let me know what you think.

Strategist.6132:

It’s been a month ago! Sorry for bumping this post:P I was just wondering: What is the state of the Skills and Trait API?

I’ve already seen it being mentioned before but I really think the following API could be useful:

- Account/PvP/ where you can gather statistics on the matches won and against / with who. This way people could check on their previous matches and for example check out other players statistics and things. Maybe this would also be a good way to upgrade PvP with a new better-looking leaderboard?

I am not sure how hard it is though but I really think it would improve the community!

Pat Cavit.9234:

It’s been a month ago! Sorry for bumping this post:P I was just wondering: What is the state of the Skills and Trait API?

I’ve already seen it being mentioned before but I really think the following API could be useful:

- Account/PvP/ where you can gather statistics on the matches won and against / with who. This way people could check on their previous matches and for example check out other players statistics and things. Maybe this would also be a good way to upgrade PvP with a new better-looking leaderboard?

I am not sure how hard it is though but I really think it would improve the community!

RE: /v2/skills what progress there is can be tracked here: https://github.com/arenanet/api-cdi/pull/5

It’s slowed down some as skills/traits are very complicated to represent and we’ve been focusing on things that can ship sooner and at a higher quality level.

RE: PVP endpoint. This is something we’re looking at soon, some of the data we’d want to expose already exists. A PR w/ a suggested format & data you’re interested in would be a great help in terms of giving some direction on what that API could look like.

Strategist.6132:

Alright Pat! Thanks for the quick response! I will try to make a PR somewhere this midday if I don’t forget! I am a bit new to Github so I will try to be careful, but please forgive me if I mess things up.

Otokomae.9356:

Wait… is this the thread where we ask for future DirectX 12 implementation, or whatever other optimizations are required to allow kitten ,000 PC to get above 15 FPS at Claw of Jormag?

smiley.1438:

Wait… is this the thread where we ask for future DirectX 12 implementation, or whatever other optimizations are required to allow kitten ,000 PC to get above 15 FPS at Claw of Jormag?

no.

You may ask in the suggestions subforum. While you’re at it, please ask for a 64bit client which supports more than one cpu core…

Strategist.6132:

I created the new PR regarding /v2/spvp/matches. I hope I didn’t break / forget something:P

zyph.9426:

With the possibility of authentication there ought to be some guild-roster-api, but i don’t know how this should be implemented. Obviously there should be a setting in the ingame privileges tab like “API-Access” which grants those rights to a specivic guild group.

Probably not going to be an in-game opt-in for this. Anyone in the guild can already see the roster in-game, so it doesn’t make sense to hide the roster from them out-of-game.

i would be really excited about a possibility to have guild chat outside of the game too, maybe somewhat like twitch allows to connect to their irc: http://help.twitch.tv/customer/en/portal/articles/1302780-twitch-irc

Out-of-game guild chat is definitely something I want to have, but we haven’t really settled on a protocol for it yet. XMPP, IRC and “something custom with HTTP+SSE” have all been tossed around as potentials but it’s not immediately clear which is most advantageous to implement. As far as interoperability with existing clients, IRC’s probably the winner (though it’s a horrible mess of a protocol).

Go with your own protocol. People are doing chatrooms with Node.js and socket.io ever since it released. WebSockets is a nice TCP/IP wrapper and is supported on all major browsers. Its easy to write against it so I can see client apps being developed around it too. If you limit the messages to 128 bytes, you won’t have to ever implement the protocol chunking, which saves you loads of work.

IRC is older than me (I’m 24 years old), it is time to let it go xD

WebSockets usability info: http://caniuse.com/#feat=websockets

Agreed. IIRC/XMPP are dead. And agree on websockets as well. Clients will pop up everywhere if this api is realized. But the complexity in making it real will be in the logic around guild/party/map/team channel area, and not in the passing of messages once the user is in a channel. I could see the channels materialize as separate rest endpoints and leverage the API key for authentication. But the authorization part is the sticky bit.

For example, if I’m not logged into the game and not repping a guild, what chat channel do it get access to? I’m not on a map so /m channel is out, etc… Is it only available if you’re in a guild? Just lots of things to be worked out I think.

MentalFS.2589:

Out-of-game guild chat is definitely something I want to have, but we haven’t really settled on a protocol for it yet. XMPP, IRC and “something custom with HTTP+SSE” have all been tossed around as potentials but it’s not immediately clear which is most advantageous to implement. As far as interoperability with existing clients, IRC’s probably the winner (though it’s a horrible mess of a protocol).

Go with your own protocol. People are doing chatrooms with Node.js and socket.io ever since it released. WebSockets is a nice TCP/IP wrapper and is supported on all major browsers.

Agreed. IIRC/XMPP are dead. And agree on websockets as well. Clients will pop up everywhere if this api is realized.

I wouldn’t say they’re dead, but I also don’t think they should be forcefully used as a gateway. Most services that offer IRC or XMPP access do that because they use those as their underlying backbone. Twitch and Facebook/Google Talk comes to mind here. But with Facebook/Google you can also see where this leads: Their services moved away from the old backends and they had to build gateways for backward compability. Facebook already ditched that and Google lets the gateway rot until everyone is glad when they pull the plug.

Assuming Guild Wars 2 is not using an XMPP or IRC server internally, it would start out as a gateway, with all the horrible choices about how to represent things in that protocoll. And while one could hope that lots of clients would work out of the box, a lot will have their problems because of some tiny unwritten or hard to find rules between all those RFC, XEP and stuff that’s always copied from other clients implementations.

Ironically, the first thing to do would be to implement a proper API first and then create a gateway around it. So the best choice would be to omit the gateway building part, make an own API with whatever technology that’s preferred and let the community do the rest. If there’s demand, there will be lots of things popping up: libpurple plugins, plugins for other multi chat clients, Jabber transports, IRC gateways/bitlbee plugins and of cause clients that directly use the API.

LadyRhonwyn.2501:

Would it be possible to add map completion status and currently selected storyline to the character details API?

I did notice that the character select screen now shows crafting professions, but we still can’t show map completion!

Lawton Campbell.8517:

Would it be possible to add map completion status and currently selected storyline to the character details API?

It’s definitely something that can be done, but I haven’t started on it yet.