Mobile and native clients
Native applications use the same JSON authentication, short-lived access tokens and rotating refresh sessions as other application clients.
Sign in
POST /api/v1/auth/login
Content-Type: application/json
{"email":"nick@example.com","password":"correct horse battery staple"}Send the returned access token as Authorization: Bearer .... Store the refresh token in Keychain, Android Keystore or the platform's equivalent protected credential store, never ordinary preferences or logs.
Rotate atomically
- Read the current refresh token from secure storage.
- Exchange it exactly once.
- Persist the replacement refresh token before treating the operation as complete.
- Discard the old token and update the in-memory access token.
- If the exchange response is lost, sign in again rather than replaying an already-consumed token indefinitely.
Authenticated request
GET /api/v1/collections/issues/records?limit=25
Authorization: Bearer $ACCESS_TOKENOffline and reconnect behavior
Cache product data according to your own threat model, not refresh credentials. Resume record lists from cursors where valid and reconnect realtime streams with the last processed event sequence. Handle 401 by attempting one controlled refresh, then return the user to sign-in.
Logout
Call the application logout/revocation endpoint while online, then delete both access and refresh material locally. Server-side revocation matters because deleting a local token alone does not invalidate a copied credential.