That sounds like an error in the specification of the client-server API or an erroneous implementation on the server side for the last version: nothing should be signaled via presence or absence of fields when using JSON exactly because, as I described in my last post, the standard with JSON is that stuff that is not present should be ignore (i.e. it has no meaning at all) for backwards compatibility, which breaks if all of the sudden presence or absence are treated as having meaning.
Frankly that there isn’t a specific field signalling authorized/not-authorized leads me to believe that whomever has designed that API isn’t exactly experienced at that level of software design: authorization information should be explicit, not implicit, otherwise you end up with people checking for not-in-spec side effects like you did exactly for that reason (i.e. “is the no data being returned because of user not authorized or because there was indeed no data to retunr?”), which is prone to break since not being properly part of the spec means any of the teams working on it might interpret things differently and/or change them at any moment.
In the West there are generally two big queues for immigration:
Americans don’t (yet) qualify for the first queue and as for the second one it really depends on your skillset and wealth (if I remember it correctly Canada does have a VISA for people who bring enough money). Mind you, the skillset required to qualify for queue #2 is often not what one would expect - I vaguelly remembers something like “plumbers” and “pastry chefs”. It’s well worth it to check what are in-demand skills of the country you want to immigrate to if you need a VISA.