Web, Mobile, and BFF Integration

There are two different integration types, and their credentials are never mixed.

A third-party company’s own web or mobile app

Browsers and distributed mobile apps are not trustworthy places to store a secret. A third-party interface talks only to its own backend or Backend-for-Frontend (BFF) layer. The long-lived Frigolive client secret stays in that backend’s secret vault. The backend obtains a short-lived Public API access token and calls Frigolive server-to-server.

This model gives the customer full freedom over design, branding, and product flow, while Frigolive remains the single source of truth for device, telemetry, shipment, and alarm data.

The official Frigolive mobile app

The mobile app built for Frigolive carries no Public API client secret. Users sign in with an email OTP, with Google, or — in permitted development environments — with a password. The app receives a one-hour user access token plus a rotating 30-day refresh token. The refresh token is replaced on every use; the session is revoked immediately when the user signs out or an administrator ends the session.

Tokens are stored only in secure storage backed by the iOS Keychain or the Android Keystore. The access token should be used from app memory and must never be written to logs, analytics events, crash reports, or source code.

Mobile developers use two documentation surfaces:

• /api/mobile/docs/: sign-in, setup, sessions, app policy, and the push contract
• /api/docs/: device, telemetry, shipment, company, and role endpoints reached with a user role; available to authorized staff only

After sign-in the app should call /api/mobile/v1/bootstrap/ and use the returned resource addresses instead of hard-coding them.

Caching and account switching

Cache keys must combine the Frigolive account id with your own user scope. When the account changes, data from the previous account must not appear on the new screen, not even briefly.