DUPLICATE – see comments

The API endpoint for determining a player's UUID given a username and timestamp (documented here) is ignoring the "at" parameter and only ever returning the current player with that username.

To demonstrate, here is a player that changed their name twice:

➜ curl "https://api.mojang.com/user/profiles/71a75aaae2a34938850dc97c07507d97/names" | jq

[
  {
    "name": "HowdyDonut"
  },
  {
    "name": "LoopyKazoo",
    "changedToAt": 1575342738000
  },
  {
    "name": "HowdyDonut",
    "changedToAt": 1602456240000
  }
]

We would then expect the following results when calling the username/time -> UUID endpoint (note that timestamps are converted from epoch millis to seconds, as required):

• LoopyKazoo, 1575342738 => 200 / OK
• HowdyDonut, 1575342738 => 204 / NOT FOUND

However, instead, we get the following results:

• LoopyKazoo, 1575342738 => 204 / NOT FOUND
• HowdyDonut, 1575342738 => 200 / OK

➜ curl "https://api.mojang.com/users/profiles/minecraft/LoopyKazoo?at=1575342738" | jq

# (no response body)

➜ curl "https://api.mojang.com/users/profiles/minecraft/HowdyDonut?at=1575342738"

{
  "name": "HowdyDonut",
  "id": "71a75aaae2a34938850dc97c07507d97"
}

Furthermore, I have noticed that I can pass nonsense input via the "at" parameter without triggering a 400 / BAD REQUEST.

➜ curl "https://api.mojang.com/users/profiles/minecraft/HowdyDonut?at=ayy-lmao" | jq

{
  "name": "HowdyDonut",
  "id": "71a75aaae2a34938850dc97c07507d97"
}

So it seems likely that the API is ignoring the "at" query parameter. That would explain why the param is not validated and the endpoint only ever returns the current UUID for the username at hand.