api.mojang.com doesn't return UUID for "Steve" account
The account Steve does exist. It has the UUID 8667ba71b85a4004af54457a9734eed7.
This can be verified via https://sessionserver.mojang.com/session/minecraft/profile/8667ba71b85a4004af54457a9734eed7.
https://api.mojang.com/users/profiles/minecraft/Steve returns a 204 No Content instead of returning the UUID as usual.
Making a POST to https://api.mojang.com/profiles/minecraft with ["Steve"] returns an empty array instead of returning the UUID as usual.
I think this issue may be related to user 0621d1ddc64d4d8285be91995a753c53 who has renamed their account from steve (with a lower case s) to Volcano_man on 17 Feb 2015 04:31:28 UTC, see https://api.mojang.com/user/profiles/0621d1ddc64d4d8285be91995a753c53/names
I think this issue may be related to that user.
does work: https://api.mojang.com/users/profiles/minecraft/Steve?at=1424147488
does not work: https://api.mojang.com/users/profiles/minecraft/Steve?at=1424147489
Created Issue:
api.mojang.com doesn't return UUID for "Steve" account
The account Steve does exist. It has the UUID 8667ba71b85a4004af54457a9734eed7.
This can be verified via https://sessionserver.mojang.com/session/minecraft/profile/8667ba71b85a4004af54457a9734eed7.https://api.mojang.com/users/profiles/minecraft/Steve returns a 204 No Content instead of returning the UUID as usual.
Making a POST to https://api.mojang.com/profiles/minecraft with ["Steve"] returns an empty array instead of returning the UUID as usual.
I think this issue may be related to user 0621d1ddc64d4d8285be91995a753c53 who has renamed their account from steve (with a lower case s) to Volcano_man on 17 Feb 2015 04:31:28 UTC, see https://api.mojang.com/user/profiles/0621d1ddc64d4d8285be91995a753c53/names
I think this issue may be related to that user.does work: https://api.mojang.com/users/profiles/minecraft/Steve?at=1424147488
does not work: https://api.mojang.com/users/profiles/minecraft/Steve?at=1424147489
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
MC-78198 → 
WEB-12![[Mojang] Kristoffer Jelbring](../../../data/avatars/users/10122.svg){kind=small}
[Mojang] Kristoffer Jelbring
By the way Steve also has a cape:
{ "timestamp": 1425138153195, "profileId": "8667ba71b85a4004af54457a9734eed7", "profileName": "Steve", "textures": { "CAPE": { "url": "http://textures.minecraft.net/texture/8dfc8f4f35995404e7a4ac7e3271d39444ccf1a6e067896d90eacd657d22b1" } } }I suspect this is because it's a legacy account.
You may suspect it, but it it's actually the case. Feel free to check: https://sessionserver.mojang.com/session/minecraft/profile/8667ba71b85a4004af54457a9734eed7
Yep. Definitely legacy.
Definitely legacy and definitely has a cape.
And other legacy accounts are returned by the API - so that's no excuse.
Maybe related to the reasons behind
MC-53291?Due to reasons I rather not go in to the profile name Steve has special status in our system and therefore most normal API calls won't work with the name Steve. That name change should not have been allowed. It slipped through due to a bug in the system. I've removed the name change from history so now it will at least be consistent.
Thanks @KrisKelbring, but can you take another look? 8667ba71b85a4004af54457a9734eed7 still returns "Steve" as a valid account.
Edit: or is it actually supposed to be a valid account (with a valid uuid) that's just handled differently?
Technically the profile does exist (as a legacy user) which is why you can look it up using the session API. The session API doesn't care about the state of the profile which is why you also can fetch information on deleted profiles etc.
Out of curiosity, what are you using these lookups for?
We use some parts of the API for Crafatar (source code).
Some similar services are hardcoding 'char' (thanks to this file name) to always return a steve face, but since renames are allowed, char has become a valid account with a non-steve skin.
I somehow™ noticed there was a UUID for Steve and I was just wondering if this could happen to the 'Steve' account as well and if it might end up having a non-steve skin as well.
If Steve will never have a custom skin, we don't need to look up anything and save a request to your API.
While we're at it, is 'Alex' a special account, too, or is that a legit user (which might have a custom skin at some time)?
And is it correct that 'Steve' is supposed to have a cape? Can that cape change in future?
Interesting. I guess you (and probably others too) would benefit from having a proper way of looking up profiles through the offical API (api.mojang.com).
If you want to reference a user that always has a Steve or Alex face you can use the MHF_ accounts (see http://minecraft.gamepedia.com/Mob_head for more info).
As far as I know Alex is just a regular account. There's no special handling around the name Alex. I'm not really sure if the Steve account is supposed to have a cape or not but it could potentially change in the future.
Is there an endpoint at api.mojang.com that returns skin and cape? As far as I'm aware, only
https://sessionserver.mojang.com/session/minecraft/profile/{uuid}returns a base64 encoded JSON object with that info. There's the legacy skins.minecraft.net, but it's updating slower and doesn't support UUIDs (afaik).
I knew about the MHF_ accounts but wasn't actually aware there was one for Steve and Alex as well. Thanks!
nvm, I misread your comment and thought there is a proper way.
Indeed, that would be nice
Also thanks for your time & answering those questions
There is currently no other public API for fetching the texture information. I would definitely not recommend using the legacy service.
It's great for us to know about these use cases when we continue to develop our public APIs in the future so thanks for the feedback!
We're currently using the legacy API when we get avatar requests via username.
We also have 3D renders and we don't know if they should be rendered as slim model or the 'standard' model.
Unfortunately there's currently no way for us to fix this. We thought about resolving names to uuids, but that API is limited to 600 requests per 10 minutes (i.e. 1 per second) and we get a lot more requests than that.
FYI: We've discussed this problem here and the slim model issue here