Resolve Docs Locale Platform And Theme
Operator reference for how Docs API requests normalise locale, platform, device, theme and API search inputs before returning an index or article response.
In this article
Use this guide when you need to confirm how a Docs index or article request will be interpreted before Antylogic returns documentation content.
Public and authenticated Docs routes share the same resolver and content bundle. The route prefix controls authentication; query parameters control language, device family, media theme and API-side search.
Before you start
- The request targets a non-asset route under /api/public/docs or /api/app/docs.
- For GET requests, the Docs content bundle is available from DOCS_CONTENT_PATH or the default backend docs content path.
- For /api/app/docs, the Harbor Demo User or another app user is already authenticated through the app API middleware.
- Optional inputs may be supplied as locale, platform, device, theme, q or the Accept-Language header.
Instructions
- 1.
Choose the Docs route
Use /api/public/docs for unauthenticated documentation responses. Use /api/app/docs from an authenticated app session. Both prefixes call the same option resolver after route, method, asset and content-bundle checks pass.
- 2.
Resolve the language
Pass locale when the client needs a specific Docs language. locale takes priority over Accept-Language; en-GB resolves to en. If no supported language is supplied, the backend falls back to es.
- 3.
Resolve platform or device
Pass platform when the client already knows the target form factor. If platform is blank, device is used instead. iphone, ios, android, phone, mobile, movil and móvil resolve to API platform mobile and internal media platform iphone. desktop resolves to web.
- 4.
Resolve the theme
Pass theme=dark only when dark documentation media should be preferred. Any blank or unsupported theme resolves to light. Index responses do not echo theme; article detail responses do.
- 5.
Use API search deliberately
Use q only on index routes when an API consumer needs server-side filtering, for example q=reservations. The native and landing visible Docs search boxes filter the already-loaded index locally, so they should not be documented as sending q to /api/app/docs.
- 6.
Read the echoed response
On index responses, confirm locale, platform, article_count, sections and optional query. On article responses, confirm locale, platform, theme and media resolution fields such as resolved_platform or resolved_theme when media is present.
Validations and limits
- Only GET and HEAD are accepted on non-asset Docs routes; other methods return 405 before option resolution.
- Non-asset HEAD checks and /assets/... requests are handled before options are resolved.
- Unsupported locale, platform, device and theme values are canonicalised to defaults instead of being rejected.
- Only en and es are implemented by the backend locale normaliser; the backend default is es.
- Only mobile, tablet and web are represented in API platform responses; internal media selection uses iphone, ipad or web.
- q is trimmed only. Blank q is omitted from JSON, and q on article detail routes is stored by the resolver but not used by article lookup.
- Public Docs routes do not require authentication. Authenticated app Docs routes require a bearer token or access_token cookie and are blocked for pending-deletion accounts.
Expected result
Operators can predict and verify the normalised Docs response fields for public and authenticated requests without confusing API-side q filtering with the visible local search in the Docs screens.