Scopes and Account Isolation
Authentication decides which backend service is connecting. Authorization decides what that service may do, and in which account. Frigolive keeps those two decisions separate and re-evaluates both on every request.
The three-way check
- Credential account allow-list: an integration can only select the real customer accounts opened to it.
- Access token scopes: read and write permissions are separate for every resource.
- Tenant resource ownership: the resource must genuinely belong to the selected account.
Passing only one of these checks is not enough. A token with the device read scope still cannot see a device belonging to an account outside its allow-list.
Multi-account header (X-Frigolive-Account-ID)
A single credential can be opened to several real accounts within a company group. In
that case every data request names the target account explicitly through the
X-Frigolive-Account-ID header.
The Public API covers only the official endpoints defined for customers to exchange data with their own systems. Security and permission checks are validated independently on every request.
Permission groups
The following resource groups can be granted independently:
- Accounts:
accounts:read,accounts:write - Locations:
locations:read,locations:write - Carriers:
carriers:read,carriers:write - Receivers:
receivers:read,receivers:write - Alert presets:
alert-presets:read,alert-presets:write - Shipment templates:
shipment-templates:read,shipment-templates:write - Devices:
devices:read,devices:label:write,devices:settings:write - Telemetry and maintenance:
telemetry:read,maintenance:read - Shipments:
shipments:read,shipments:write,shipments:complete,shipments:share,shipments:tracking:read - Alarms and reports:
alarms:read,alarms:write,reports:read - Users:
users:read,users:write,users:invite
The most professional starting point is the smallest scope set the integration will actually use. An integration that only renders a map, for example, has no need to invite users or delete shipments.