Antylogic
DemoApp login

399 operational guides

Docs sections
DocsDocumentation
Device

Get Authenticated Docs Article

Verify how a signed-in Antylogic app session opens a localised Docs article, receives the authenticated article detail JSON, and renders the same content in the native Docs screen without changing demo data.

In this article

Use this guide when support, documentation, or QA needs to confirm that Harbor Demo User can read the Access article for Harbor Soho through the authenticated Docs API and the native Docs screen.

The action is read-only. It resolves content from the shared Docs bundle, normalises locale, platform, and theme options, and returns planned media safely when no asset has been generated yet.

Before you start

  • Harbor Demo User is signed in to Harbor Demo Group with the GB demo runtime selected.
  • The account is not pending deletion, because pending-deletion accounts are blocked before the Docs handler runs.
  • The Docs content bundle is available through `backend/docs-content/articles.json` or the configured `DOCS_CONTENT_PATH`.
  • The GB example article exists as section `access` and article `en-access-users-create-location-internal`.
  • For native verification, load the Docs index first so the screen can resolve `section_slug` and `slug` before requesting detail.

Instructions

  1. 1.

    Start From A Signed-In App Session

    Open the article only from an authenticated app context. `/api/app/docs` requires the same bearer token or `access_token` cookie used by the app, and the token must resolve to a non-empty user ID.

  2. 2.

    Resolve The Article In Docs

    Open `antylogic://docs/access/en-access-users-create-location-internal`. The native Docs screen loads the index, finds the Access section and article slug, then enables the article detail request.

  3. 3.

    Request The Localised Detail

    Call `GET /api/app/docs/access/en-access-users-create-location-internal?locale=en-GB&platform=mobile&theme=light`. The response locale normalises to `en`, platform resolves to `mobile`, and theme stays `light`.

  4. 4.

    Review The Article Payload

    Confirm that the response includes `version`, `locale`, `platform`, `theme`, `section`, and `article`. The article should be `Create an Internal Location User` in the `Access` section, with intro, prerequisites, steps, validations, result, and media fields.

  5. 5.

    Check Planned Media Behaviour

    Media entries with no resolved source should not fail the article. They remain planned in JSON and appear in the app as a pending resource instead of successful playback.

  6. 6.

    Treat Missing Content As Availability

    If the bundle is missing, invalid, or the article cannot be found, handle it as a documentation availability or not-found condition, not as an operator data issue.

  7. 7.

    Prefer The Explicit Route

    Use the two-segment route in manuals and captures. The single-slug fallback can return another locale after the locale-specific lookup fails, and `HEAD` only checks route availability.

Validations and limits

  • Only `GET` and `HEAD` are accepted for Docs article detail.
  • Authentication is required for `/api/app/docs`; public Docs routes are separate.
  • Pending-deletion accounts are blocked by the shared app API gate.
  • No extra Docs role, organisation permission, or location permission is enforced for this read-only detail route.
  • `locale=en-GB` resolves to `en`; unsupported or blank locales fall back to `es`.
  • `platform=mobile`, `iphone`, `ios`, `android`, or `phone` resolves to API platform `mobile` and content platform `iphone`.
  • Only `theme=dark` resolves to dark; every other value resolves to light.
  • For `/api/app/docs/{sectionSlug}/{articleSlug}`, the article must match the normalised locale and section slug.
  • Article slug matching accepts the normalised article `id`, `sourceGuideId`, or title.
  • Resolved media URLs are emitted under `/api/app/docs/assets/...`; empty or invalid media source paths leave `src` empty.
  • The action does not create or update users, locations, organisations, support tickets, documentation content, or media assets.

Expected result

A signed-in Harbor Demo User session can verify that the authenticated JSON detail response and the native Docs article both represent the same Access article, including planned media handling, without mutating any operational data.

Related articles