api.mojang.com/users/profiles/minecraft/<name> inconsistency with 'at' parameter
the results when using the at parameter for different names is very inconsistent.
For example, ?at=0 can be used to get the first name, but this only seems to be working for accounts that have been renamed at least once:
https://api.mojang.com/users/profiles/minecraft/Djinnibone?at=0
or accounts that are legacy:
https://api.mojang.com/users/profiles/minecraft/noobkackboon?at=0
however, it does not work with (non-legacy) accounts that haven't been renamed:
https://api.mojang.com/users/profiles/minecraft/Notch?at=0
I am not actually using this to find the first name of a user but it's an inconsistency in the API. You can replace 0 with any timestamp before the account's existence (the date may be unknown so such a request isn't too uncommon).
I guess this is related to different handling of usernames/dates since the name changes have been introduced.
That also leads to the question what the API returns for the same query for a user created after the name change. Are there any differences?
Created Issue:
api.mojang.com/users/profiles/minecraft/<name> inconsistency with 'at' parameter
the results when using the at parameter for different names is very inconsistent.
For example, ?at=0 can be used to get the first name, but this only seems to be working for accounts that have been renamed at least once:
https://api.mojang.com/users/profiles/minecraft/Djinnibone?at=0or accounts that are legacy:
https://api.mojang.com/users/profiles/minecraft/noobkackboon?at=0however, it does not work with accounts that haven't been renamed:
https://api.mojang.com/users/profiles/minecraft/Notch?at=0I am not actually using this to find the first name of a user but it's an inconsistency in the API. You can replace 0 with any timestamp before the account's existence (the date may be unknown so such a request isn't too uncommon).
I guess this is related to different handling of usernames/dates since the name changes have been introduced.
That also leads to the question what the API returns for the same query for a user created after the name change. Are there any differences?
the results when using the at parameter for different names is very inconsistent.
For example, ?at=0 can be used to get the first name, but this only seems to be working for accounts that have been renamed at least once:
https://api.mojang.com/users/profiles/minecraft/Djinnibone?at=0or accounts that are legacy:
https://api.mojang.com/users/profiles/minecraft/noobkackboon?at=0however, it does not work with (non-legacy) accounts that haven't been renamed:
https://api.mojang.com/users/profiles/minecraft/Notch?at=0I am not actually using this to find the first name of a user but it's an inconsistency in the API. You can replace 0 with any timestamp before the account's existence (the date may be unknown so such a request isn't too uncommon).
I guess this is related to different handling of usernames/dates since the name changes have been introduced.
That also leads to the question what the API returns for the same query for a user created after the name change. Are there any differences?
Incomplete without a crash report from (minecraft/crash-reports/crash-<DATE>-client.txt). Please attach it so that we can diagnose your issue.
But most likely
MC-38527
duplicates
is blocked by
As Ined mentioned in WEB-13,
We no longer support the at parameter for this endpoint.
If that is the case, this issue should be closed.
@Mustermaster1402
You can still request username history if you know his uuid.
And since the swap from names to uuids was 10 years ago there shouldn't be any database or other userdata storage which is solely based on names in 2022.
And you apparantly cannot read. In WEB-13 is was said that the parameter was removed INTENTIONALLY. You won't get it back.
Edit: Also projects exist to use namemc as api like https://github.com/jaqobb/namemc-api so I really don't see the problem here.
Confirmed
Create in 2015 but not fix in 2017...
I'll go ahead and close this. We no longer support the at parameter for this endpoint.