Authentication Overview

The IndiTrace web app is built on the same REST API described here. There are two kinds of request:

• Public lookups — the trace and verify endpoints behind every QR code need no authentication.
• Signed-in requests — everything else uses the session tokens the app itself uses.

There are no long-lived API keys and no self-serve integration credentials yet. If you want to integrate a system with IndiTrace, contact us and we will set it up with you.

Session tokens (JWT)

Signing in returns a short-lived access token and a refresh token:

POST /api/v1/auth/login/
Content-Type: application/json

{"email": "you@example.com", "password": "••••••••"}

{
  "access": "<access token>",
  "refresh": "<refresh token>",
  "user": { "id": 42, "email": "you@example.com", "organization": { "id": 7, "name": "…" } }
}

Accounts with two-factor authentication answer {"code": "2fa_required", "challenge": "…"} instead; post the emailed code with the challenge to /api/v1/auth/login/verify-otp/ to receive the tokens.

Send the access token on every request:

Authorization: Bearer <access token>

• Access tokens expire after 15 minutes. Exchange the refresh token at POST /api/v1/auth/token/refresh/ ({"refresh": "…"}) for a new pair; each refresh token works once.
• Refresh tokens last 14 days. Changing the password revokes every token.
• POST /api/v1/auth/logout/ with {"refresh": "…"} revokes both the refresh token and the access token used for the call.

Errors

Good practice

1. Keep tokens out of URLs, logs and source control.
2. Refresh once and share the result when several requests fail at the same time; refresh tokens rotate.
3. Treat a 401 from the refresh endpoint as signed out.