Two part answer: General Thoughts and an actual answer below:
From the context of the general application, I think you should specifically not try to do what you are asking how to do. A general rule of thumb I live by is that API endpoints should always return a proper API response.
For example, Marstato's answer will certainly accomplish what you are trying to do, but there are some unintentional downsides that can cause trouble down the road. Mainly, your accept-header is now effectively acting as a routing parameter. What happens if you accidentally remove that header from your request in angular down the road? What happens if another developer joins and attempts to implement the API call themselves not realizing the importance of the accept header? In both cases the result will be the same: they won't get back a true or a false, but instead will get back something else entirely. And that will be very confusing.
Again, there are certainly ways to do what you want to do, but I think the real answer is that you really shouldn't try to do that. Your API endpoints are for your developers only, and any response that can potentially confuse your developers is a bad response and shouldn't be returned by an API endpoint.
Yes, it is possible for users of your site to get to the URL in question and see a white screen with "false". However, your API endpoints should be bundled up and invisible to the end user, so there really is no reason why anyone should end up at example.com/authorized in order to see that screen. Clearly separating your api calls (e.g. api.example.com/authorized or example.com/api/authorized) is a good way of minimizing the chances of someone accidentally stumbling on your API urls, while also making your system a bit more organized.
So my general answer is that the likelihood and harm of someone accidentally stumbling on your API urls is (or should be) low enough that it isn't worth the extra logic in your API calls, especially since a non-standard response from the API may confuse yourself or other developers down the road.
If you really do want to do this though, another way to do it would be to check for lack of login credentials. Presumably your API call is more than just a simple GET request? The API call is returning true/false depending on whether or not the user is authorized, correct? This means that the API call knows what user is being authorized, which means that user credentials are coming up in the request. Since you are doing a GET request that means that the credentials are either in the header, in a cookie, or in the URL parameters. Cookies shouldn't be used for API calls, so best guess is that the user's credentials are in the HTTP header in some form. However, if a user simply browses to example.com/authorize in their browser, those credentials will not be present. As a result you could just assume that a browser is being used if absolutely no user credentials are present in the HTTP header, and otherwise return a normal API call if credentials are present. The same also holds true if you are accepting the user credentials in the URL parameters (although that would be weird).