Getting Started

Everything a mobile client needs to talk to the Super People API. The mobile app uses the same API as the web app — there is no separate mobile backend and no separate set of routes. What differs is only how the session is carried: the web app rides a cookie, the mobile app holds a bearer token.

• Interactive reference (always current): GET /api/v1/docs
• Machine-readable spec: GET /api/v1/openapi.json (or .yaml)

Generate a typed client from the spec rather than hand-writing models:

# Kotlin / Swift / Dart — pick your generator
npx @openapitools/openapi-generator-cli generate \
  -i http://localhost:3101/api/v1/openapi.json -g kotlin -o ./generated

If you would rather work from a file than a running server, ask the backend team for a snapshot — npm run openapi:export -w api writes one. It is deliberately not committed to the repo: a checked-in copy goes stale the moment a route changes, and the endpoint above is always current.

Maintainers: every page under API Reference is generated from that spec by npm run docs:api -w api. Do not hand-edit them — change the @ApiOperation / @ApiProperty decorators in apps/api/src/ and regenerate. The guides are hand-written and safe to edit.

EnvironmentsCopy Anchor Link

Every route in the API Reference is relative to that base URL. All paths start with /api/v1.

On Android, a debug build talking to a developer machine needs http://10.0.2.2:3101 (emulator) and a cleartext-traffic exemption; production is HTTPS only.

Validate a base URL before you have a token:

GET /api/v1/health

{ "status": "ok", "version": "1.0", "time": "2026-09-10T07:16:23.096Z" }

This is the only route that needs no session. Everything else answers 401 without one — which is why it exists: a wrong base URL and an expired session otherwise look identical.

Where to go nextCopy Anchor Link

• Authentication, then the API Reference for the module you are building, is enough to start.
• Conventions, Media and The Content Model are the rules that will otherwise bite you.