New API: Inconsistencies with Kua'fon

API Bug Report
1

Hello! I am currently working on updating my web site to use the new Profile APIs instead of the old Community APIs. I am running into many issues.

One issue is that the new API does not handle the Kua’fon mount the same way between different endpoints.

When retrieving the master list, there is only a single version of the Kua’fon mount:

  • /data/wow/mount/index?namespace=static-us
  • { key:{ href:’…’ }, name: “Kua’fon”, id: 1043 }

However, when getting the mount collection of a character, there can be two versions of the Kua’fon mount. I believe one version might be the upgraded flying version of Kua’fon:

  • /profile/wow/character/drenden/shoogen/collections/mounts?namespace=profile-us
  • { mount:{ key:{ href:’…’ },name: “Kua’fon”,id: 1043 } }
  • { mount:{ key:{ href:’…’ },name: “Kua’fon”,id: 1264 } }

This is not a major issue, but it would be nice if the mount was treated the same way in both endpoints, so that data lookups/mappings do not fail. Thank you!

1 Like
2

That’s odd! I’m curious now if anyone has the latter version. The mount database in the game client only lists the 1043 one.

2 Likes
3

Yep it is definitely odd! I myself seem to have the latter version, the URL I provided is my profile (Shoogen @ US-Drenden) and should demonstrate the issue.

I’ve noticed that some other things are missing from the mount/pet database I got from wow.tools, such as the Ensorcelled Everwyrm (id=1289). So maybe some mounts are treated differently in some way? Such as ones that are hotfixed in? Really not sure.

2 Likes
4

Thank you all for the report and discussion. It was helpful to me just now when I ran into this issue myself.

5

Sorry! I somehow missed this. Is the different ID appearing in the community API too? Or just the new player one? Actually, I shouldn’t be lazy - I’ll check it out in a sec :slight_smile:

As for the Ensorcelled Everwyrm not appearing in the mount table on wow.tools - it is now, but the reason it wasn’t originally was either that it was initially encrypted and the table wow.tools was displaying hadn’t had the decrypt applied, or it was only appearing in the game cache at the time (the cache contains updates and hotfixes to certain data, sometimes well before they’re applied to the tables the build ships with). Either way, it’s almost certainly because they wanted the mount to be a secret until its announcement.

6

Hello Wain!

I am not sure if you got a chance to check it out, but yes, the old community API would return 2 versions of the Kua’fon mount.

  • /wow/mount/
  • Includes both Kua’fon (spellId=301841) and Kua’fon (spellId=267270)

And the character profile

  • /wow/character/drenden/shoogen?fields=mounts
  • Includes both Kua’fon (spellId=301841) and Kua’fon (spellId=267270)

Thanks for the extra info regarding the Ensorcelled Everwyrm as well! I had assumed it was something along those lines. I am not sure if perhaps this 2nd version of Kua’fon was being treated in a similar way, and this is why we cannot see both versions inside the mount database in the game client (which is a comment you had originally mentioned).

Hopefully Blizzard can make some fixes to the APIs here, though again, this is not a huge priority issue compared to some of the other bugs.

7

Thanks! Yeah, at you could ignore the ‘upgraded’ version of Kua’fon and just look for the basic one, which everyone who owns the mount must have. Unless the new profile ID only returns the upgraded one, then it would require a hardcoded check, but hopefully not.

8

Just for the reminder - the issue is still exists. Getting the mount list for the character (using the new api) still returns the both versions of Kua’Fon, but the mount info returns error for the mount id:1264. E.g. still need maually fixing the “Kua’Fon issue”.

9

Greetings everyone,

We are looking into this issue but are not able to provide an ETA on a resolution at this time. Thank you for your patience.