Apr 16, 2014 at 9:33 PM
It seems the feature update has pretty much broken the entire Api. There is something discussed here:
However this is not much, and therefore we sadly have to wait.
Apr 17, 2014 at 8:28 AM
I don't think that they actually make any breaking changes to the API. At least my code seems to work even after the update.

What's weird though is that the events endpoint is still returning data. -> still works?!

However certain events have been removed. -> wiki example now returns an empty collection

I presume that events are removed from the API when their containing map is upgraded to a Megaserver map. So eventually, the events endpoint will return an empty collection even without filters.
Apr 17, 2014 at 10:59 AM
That and apparently something with item_names is broke, but will be fixed in the next few days.
Apr 19, 2014 at 11:40 AM
Edited Apr 19, 2014 at 11:41 AM
There's a new wardrobe API. See:

So yeah. I don't think that any of these changes have actually set us back. I'm just really annoyed that I don't have time to work on this project. I would love to get the new skins API out as soon as possible, but real life keeps getting in my way.
Apr 21, 2014 at 8:42 PM
I'm doing a presentation for a school project tomorrow. If all is well, my tutor will finally get off my back, so I can start working on things that I really want to be working on again. Tomorrow will probably be the first time in over 4 weeks that I haven't had any deadlines to meet.
Apr 22, 2014 at 2:54 PM
Huraaay. I'll see if I can do a bit coding, so I get used to the structure.
Apr 23, 2014 at 2:54 PM
Edited Apr 23, 2014 at 8:36 PM
Alright. They broke it. Some existing endpoints had their object schema changed.

For example, the items.json endpoint used to return an array.
Now it returns an object.

All issues should be fixed now.
Apr 23, 2014 at 11:55 PM
skin.json and skin_details.json are implemented as well. I think that's about it for bugfixes and feature releases. Back to caching now.
Apr 24, 2014 at 6:08 PM
Ok, I'll bring out a release this evening (hopefully).
May 3, 2014 at 9:40 PM
I've fixed some more crashes that were the direct result of undocumented changes to the item details endpoint. Can you update the Nuget package?
May 5, 2014 at 6:46 PM
Edited May 5, 2014 at 7:58 PM
Will do asap

/edit: done
May 11, 2014 at 9:00 PM
Edited Jun 18, 2014 at 8:11 AM
I added a new service to the library: IDynamicEventRotationService

This service returns a collection of dynamic events and their scheduled start times.

Because no official API exists, this service gets its data from a hardcoded XML file (Rotations.xml). This XML file is embedded in the DLL, mainly to prevent a user from messing with the data format. While this means that the library has to be recompiled if/when the schedule changes, I think that this is acceptable considering that a new schedule would require a new game build.

Usage example
var rotations = serviceManager.GetDynamicEventRotations();

foreach (var rotation in rotations)
    Console.WriteLine("Event ID: {0}", rotation.EventId);

    foreach (var shift in rotation.Shifts)
        Console.WriteLine("Starts at: {0}", shift.LocalDateTime.TimeOfDay);
Event ID: 03bf176a-d59f-49ca-a311-39fc6f533f2f
Starts at: 02:00:00
Starts at: 07:00:00
Starts at: 09:00:00
Event ID: f7d9d427-5e54-4f12-977a-9809b23fba99
Starts at: 02:15:00
Starts at: 04:15:00
Starts at: 06:15:00
Usage example

Events can also be listed chronologically by using a clever LINQ statement:
var rotationsByShift = from rotation in serviceManager.GetDynamicEventRotations()
                       from shift in rotation.Shifts
                       group rotation by shift into rotations
                       orderby rotations.Key.LocalDateTime
                       select rotations;

foreach (var rotation in rotationsByShift)
    foreach (var dynamicEvent in rotation)
        Console.WriteLine("{0}: {1}", rotation.Key.TimeOfDay, dynamicEvent.EventId);
00:00:00: 03bf176a-d59f-49ca-a311-39fc6f533f2f
00:15:00: f7d9d427-5e54-4f12-977a-9809b23fba99
00:30:00: e6872a86-e434-4fc1-b803-89921ff0f6d6
00:45:00: 33f76e9e-0bb6-46d0-a3a9-be4cdfc4a3a4
01:00:00: 5282b66a-126f-4da4-8e9d-0d9802227b6d
Jun 18, 2014 at 8:12 AM
Edited Jun 18, 2014 at 10:56 AM
Exciting news! The v2 API is going up soon.

More information:

Jun 19, 2014 at 7:18 PM
/v2/accounts [d]
/v2/characters [d]
/v2/commerce/exchange [d]
/v2/commerce/listings [d]
/v2/events [l,d]
/v2/events-state [d]
/v2/leaderboards [d]
Those excite me the most
Jun 20, 2014 at 8:41 AM
I merged branches GW2.NET and GW2.NET-Http so that I can start working towards V2. I have enough information to determine what I have to change in the current implementation to get V2 up and running as soon as possible when it's released.
Jun 20, 2014 at 1:33 PM
Good. I think It'll be best to open up a new namespace called v2 and then we can declare the V1 namespace obsolete.
Jun 22, 2014 at 11:08 AM
Edited Jun 22, 2014 at 11:12 AM
I rewrote the original IServiceClient implementation so that it can be reused for V2 when that becomes available. I also added a bunch of base classes that implement the V2 request syntax for bulk expansion. These classes can be found on the GW2.NET-V2 branch.

The interesting bits can be found here:

Updated ServiceClient implementation:

Updated RestSharp-based ServiceClient implementation:

In the meantime, I also updated the current release to 0.9.4.
Jun 24, 2014 at 4:32 PM
I had some private Stuff to do in the last few weeks, I hope I can put out the new NuGet package today or tomorrow.
Jun 24, 2014 at 9:27 PM
Ahh, must be final exams. Nearly forgot about that. So glad I dropped out of college. :)
Aug 2, 2014 at 1:13 AM
In case you haven't been paying attention: Anet has released the first /v2 API.

This update is to let you know that branch GW2.NET-V2 now implements the /v2/quaggans API.

Code sample:
var service = new Service2Manager();

foreach (var quaggan in service.GetQuaggans())
    Console.WriteLine("ID: {0}", quaggan.Key);
    Console.WriteLine("URL: {0}", quaggan.Value.Url);
This is just one of many examples. The request syntax is a lot more flexible than it used to be. Toy around with the overloads of GetQuaggans() to get a good sense of what to expect from future releases.
Aug 4, 2014 at 7:53 PM
I just read this:
Our OAuth2 implementation is basically complete. But we are awaiting actual APIs which take advantage of it before it is released. These APIs are in active development.

This sounds great.
Aug 5, 2014 at 7:08 PM
There's not much we can do until then. The only thing we can do right now is add request classes for /v2 endpoints that we already know about. If they could just release the JSON schemas already, I would be so happy.
Aug 6, 2014 at 9:02 PM
Edited Aug 6, 2014 at 9:03 PM
Oh yesh. Me too, me too. But ArenaNet is really slow in that regard. I wish the had an API as excellent as E.V.E...

BTW: Could you prepare another release with the changeset that suits you most? I think we have enough done to justify a new version.
Aug 8, 2014 at 9:35 AM
Ok, sure. Will do when I get home. I'm not sure that I remember in what state I pushed the previous release, but I'm confident that it has more bugs than the current version of the source. I'm in love with this code contracts thing. Oh, and I merged /v2/quaggans into the main branch should anyone need it (...not).
Aug 9, 2014 at 8:49 PM

For future releases, I'd like to start using the issue tracker more. I've already raised a couple of issues that I want you to take a look at. I think you can now directly edit issues to update their status (active/fixed/won't fix), manage their priority and assign a developer.
Aug 10, 2014 at 1:07 PM
yep, I think using the issue tracker is a good way of dealing with problems. I'll update the Nuget as soon as I can.
Aug 11, 2014 at 7:09 PM
Think it would be a fun idea if we wrote service adapters that translate /v2 requests to /v1 services and back? Meaning that the .NET interface would be that of a /v2 service, but the requests are routed to the /v1 service.
Aug 14, 2014 at 7:33 PM
Care to elaborate a bit more? What do you want to accomplish with it? Any benefits, drawback etc? Personally I can't see a reason why we should do this.
Aug 14, 2014 at 8:01 PM
It would allow users to write code that uses the /v2 interfaces
  • bulk requests
  • paginated requests
Under the covers, we would secretly re-route the request to /v1 services. And deal with all of the complexity that goes into converting /v1 response objects to /v2 response objects, of course.

There's not much I can say for or against the idea. But we could if we wanted to.
Aug 17, 2014 at 1:45 PM
Edited Aug 17, 2014 at 2:05 PM
So as an example, you'd be able to request item details for 10 item identifiers (/v2/items?ids=1,2,3,4,5,6,7,8,9,10). Under the covers, we'd call /v1/item_details.json ten times, once for each request identifier. Finally, we'd copy all ten response objects to a single collection before returning it to the user.

This does actually have a benefit: client code that is written in this style will not have to be updated when the real /v2 services are finally implemented. We can just swap out the implementation without even touching the public interfaces.

The obvious drawback is that making 10 requests takes 10 times as long if we don't write parallel code. And we don't know what the upper limit will be. 10 items? 100 items? 1000 items?