Service Identity and Token Lifecycle

The Frigolive Public API does not run on a human user’s password. It runs on a separate integration identity — client credentials — issued to your backend service. That separation keeps machine-to-machine data flowing when staff change or a dashboard session ends.

What the customer receives

Every integration gets a public client ID and a secret that is shown only when it is first created or rotated. The client secret is not stored in plain text in the Frigolive database. You should keep it in a backend environment variable, or preferably in a managed secret manager.

The client secret is not a permanent API token. It is only the master credential used to obtain a short-lived access token. An access token is valid for roughly one hour and carries either all of the scopes granted to the integration or the subset you request.

What happens on refresh

The Public API does not issue refresh tokens. Your backend re-runs the same client credentials flow shortly before the access token expires. If many requests need a refresh at the same time, only one token request should be started and its result shared with all of them.

When a credential is revoked or its security version is bumped, previously issued access tokens are rejected immediately, even if they have not yet expired.

Secret rotation

When a new client secret is generated, a short overlap window can be defined for the old one. Load the new value into your secret manager first, restart your services, and confirm that tokens are being issued successfully. When the overlap window closes, the old value stops working on its own.

Network-level restriction (IP allow-list)

You can optionally register allowed IP addresses or CIDR blocks. Once defined, both token requests and data calls are accepted only from those addresses, so a leaked secret cannot be used from another network.

The browser and mobile boundary

Never place the client secret in a browser, a mobile app, a Git repository, or any public code. Your interface talks to your own backend (the BFF pattern). The authorize bar in this developer portal likewise keeps only a previously issued short-lived access token in browser memory — it never accepts a client secret.