API URL Handling
API URL Handling
Overview
This page documents the current trailing-slash and proxy behavior used by the API, frontend, and nginx layers.
The important pieces are:
- the API runs with
redirect_slashes=False - the frontend client normalizes request paths in
tracker-admin/src/api/client.ts - nginx preserves the request path and forwards redirects where needed
Current Behavior
With redirect_slashes=False, the API accepts the path as written instead of issuing redirect responses for slash mismatches.
That means the client and proxy layers need to stay consistent about:
- endpoints that use a trailing slash
- endpoints that intentionally do not use one, such as auth routes
- forwarded headers when the app is behind HTTPS
Frontend
The frontend request adapter keeps API paths aligned with the current contract:
- it avoids adding a slash to auth endpoints
- it adds a slash to regular API routes when required
- it skips static file URLs
See tracker-admin/src/api/client.ts for the exact logic.
nginx
nginx handles the API in two ways:
- exact-match locations for endpoints that should not be rewritten
- a general
/api/proxy path for the rest of the API
location = /api/v1/auth/login/json {
proxy_pass __API_URL__/api/v1/auth/login/json;
}
location /api/ {
proxy_pass __API_URL__/api/;
proxy_redirect off;
proxy_intercept_errors on;
error_page 301 302 307 = @handle_redirect;
}
location @handle_redirect {
set $saved_redirect_location $upstream_http_location;
proxy_pass $saved_redirect_location;
}
HTTPS
When the app runs behind a load balancer or HTTPS proxy, also keep these headers correct:
HostX-Forwarded-ForX-Forwarded-Proto
See HTTPS Behind a Load Balancer for the HTTPS-specific side of the setup.
Troubleshooting
- If the browser sees mixed-content errors, check
X-Forwarded-Protoand redirect behavior. - If the API returns unexpected redirects, check the trailing-slash rule for that endpoint.
- If nginx cannot reach the upstream, check the
Hostheader and any upstream DNS issues.