Seems like both should give the second error. As the issue with the first request isn't the keys permissions, its that the log requested is not the one associated with the key owner.
Also, fyi error code 16 isn't documented in the API docs yet.
This also causes more weird behavior with certain fields that have different results based on if the requested data is the key owners or someone elses.
For example, personalstats. If I use my public or minimal access key to access someone elses personalstats, I get an error code 16.
But if I use my high limited/full access key to access someone elses personalstats, it works.
This is also seen when requesting my own personalstats with my own minimal/public key. I get an error code 16 instead of the publicly available version of the response. (ie with battle stats, etc removed)
I'm also seeing inappropriate error codes but under different circumstances...figure I would just piggy back off this B&I post.
"https://api.torn.com/user/?selections=Log&log=5700,5705,5710,5715,5720,5725,5730,5735,6791,8842&key=" + <Full Access API key> yields error code 16
"https://api.torn.com/user/?selections=log&log=5700,5705,5710,5715,5720,5725,5730,5735,6791,8842&key=" + <Full Access API key> works perfectly fine with the same "Full Access" API key.
The capitalized "L" in "Log" appears to be causing the error, not the API key access level, yet its returning the access level error code
Because of some limitations we really need to check that permissions first (before the relation check, for example), I afraid we can't really change this atm, perhaps we can reword the error or just leave it?
Unless we have a list of all possible selections to check first, so we can produce the "4 => Wrong fields : Requesting incorrect selection fields." error before everything else perhaps.