Skip to main content
Settings are configured per client app in the Opigno back office. When a setting has not been configured for the calling app, the API transparently falls back to the global default.

​
How the calling app is identified

The query uses the access token to identify the caller. You do not need to pass any identifier — the calling app (and therefore the hierarchy scope it belongs to) is derived from the token.
The same query also works with admin-scope tokens and authenticated user sessions; in those cases there is no app-specific scope, so the default settings are returned.

​
Available query

​
getMobileAppSettings

Returns the application settings based on hierarchy-level in auth token. 
query getMobileAppSettings {
  getMobileAppSettings {
    logoUrl
  }
}

​
Response

​
getMobileAppSettings
MobileAppSettings!
required
The settings resolved for the calling client app.

​
Resolution rules

The hierarchy scope used to look up the settings is determined as follows:
1

Identify the calling app

Opigno reads the calling app from the access token.
  • App-scoped token — the caller is identified as a specific client app.
  • Admin-scope token or user session — there is no app-specific scope, and the resolution skips straight to step 3.
2

Look up app-level settings

If the calling app has a hierarchy level assigned in the back office, Opigno reads the settings configured for that level.
3

Fall back to default settings

When no logo is configured at the app’s level (or there is no app-specific scope at all), Opigno returns the global default settings configured by the platform administrator.
This means a single global logo configured in the back office is enough for most setups; per-app overrides are optional and useful only when you ship multiple branded apps from the same Opigno tenant.

Firebase Integration

Register the device for push notifications after sign-in.

OAuth2 Authorization

Obtain the access token used to identify the calling client app.