Laravel API returning HTML instead of JSON when served via NGINX

Your first mistake is the incorrect usage of the try_files directive. The very last try_files directive argument has a completely different meaning from the preceding ones and specifies the fallback action, which can be an HTTP response status code, a fallback URI (which you are attempting to use), or the fallback named location name. Crucially, after the internal redirect performed by nginx according to your /index.php?$query_string fallback URI, a search for the most suitable location to handle the rewritten URI will be performed again. Evidently, this will not be your location /api/ { ... } block. The HTML response you are receiving is most likely the "invalid route" page from your frontend Vue.js application.

If you were using the root directive inside your location /api { ... }, it would be enough to correct this fallback URI by adding your API location prefix to it:

try_files $uri $uri/ /api/index.php?$query_string;

However, since you are using the alias directive instead of root, and your fallback URI contains variables, such a change will be insufficient due to the peculiarities of using the alias and try_files directives together, as described in this nginx trac ticket.

The simplest way to circumvent this peculiarity/bug is to use the suggestion from the most upvoted answer to the "NGINX try_files + alias directives" question, duplicating the /api/ prefix specified for the outer location directive in the fallback URI:

location /api/ {
    ...
    try_files $uri $uri/ /api//api/index.php?$query_string;

(Regardless of how strange this solution might look at first glance.)

Your second potential mistake is using the try_files directive at all within a location intended for an API controller.

This entire configuration snippet is likely a blind copy of a generic nginx configuration example for a typical PHP application. If the responses to your API requests do not involve serving static files as the response bodies, but should be processed exclusively by the central /var/www/isuecampusmap/backend/public/index.php controller (which I'm 99% certain is the case), then you do not need this entire complex and verbose construction. All you need in this scenario is to process all requests using index.php. The configuration for this is significantly simpler (and performs better):

location /api/ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME /var/www/isuecampusmap/backend/public/index.php;
    fastcgi_param DOCUMENT_ROOT /var/www/isuecampusmap/backend/public;
    fastcgi_param SCRIPT_NAME /index.php;
    fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
}

You might still be wondering why the https://isuecampusmap.site/api/ request succeeds using your configuration while every other request fails? The reason is that in this specific case, the try_files fallback argument is not engaged. As stated in the try_files directive documentation:

Checks the existence of files in the specified order and uses the first found file for request processing; the processing is performed in the current context. The path to a file is constructed from the file parameter according to the root and alias directives. It is possible to check directory’s existence by specifying a slash at the end of a name, e.g. “$uri/”.

The /api/ request maps to the /var/www/isuecampusmap/backend/public/ physical directory, which does exist, so the second check performed by the try_files directive (according to the $uri/ argument) succeeds. The try_files directive allows this request to be processed within this (outer) location. Next, the index index.php directive finds the index.php file within this directory and performs an internal redirect to /api/index.php. This behavior, although it may be surprising to inexperienced users, is explicitly documented:

It should be noted that using an index file causes an internal redirect, and the request can be processed in a different location.

Then, as already mentioned, a search for the most suitable location to handle the rewritten request will be performed again, and this time it truly will be the inner location ~ \.php$ { ... }.

Assuming the index.php file is the only file within the /var/www/isuecampusmap/backend/public/ directory, the only other request that could be handled by this location is /api/index.php (directly matching this inner location), though I doubt the API controller will be happy to see /api/index.php as a route.