Skip to main content
This page covers the app setup flow for tenant applications created from the dashboard. Tenant apps are used for machine-to-machine authentication against the backend. They are created as confidential clients and are intended for backend services, not browser-only clients.
An app can issue tokens without a plan, but the token will not include the limits claim. If the app is assigned a retired plan, token issuance is blocked. All limits are expressed in Document Units.

​
What An App Represents

Each app is an isolated machine identity under a tenant.
  • it has its own client_id and client_secret
  • it is tied to one license region at creation time
  • it stores the region-backed DbCode used during token issuance
  • it can be enabled or disabled independently
  • it can optionally have a plan assigned later

​
Creation Workflow

When you create an app in the dashboard, the backend creates a confidential OpenIddict client for the current tenant.
1

Choose A Region

Select a valid license region. The backend validates that the region exists, is active, and has an active region database available.
2

Set A Name

Enter a display name for the app. App names must be unique within the tenant.
3

Add Optional URLs

Redirect and post-logout URLs are optional. If supplied, they must be valid absolute URIs.
4

Add Allowed Domains

You can optionally store up to three allowed domains on the app.
5

Capture Credentials

After creation, the app returns a generated client_id and plaintext client_secret.
App creation fails if the selected region does not have an active region database.

​
What Gets Stored On The App

In addition to the OpenIddict client record, the app stores tenant-specific metadata used later during token issuance.
  • client_id
  • client_secret
  • LicenseRegionId
  • DbCode
  • AllowedDomain1, AllowedDomain2, AllowedDomain3
  • enabled or disabled state
  • optional PlanId

​
Allowed Domain Rules

Allowed domains are normalized and validated before they are saved.
  • http:// and https:// are stripped
  • trailing / is removed
  • wildcards are rejected
  • localhost is allowed, including localhost:<port>
  • duplicate domains are rejected
  • ports must be in the valid range
Examples:
  • https://app.example.com/ becomes app.example.com
  • http://localhost:3000/ becomes localhost:3000

​
Accessing Credentials Later

The dashboard continues to expose app metadata after creation.
  • client_id remains available
  • plaintext client_secret is shown once at creation time
  • if you regenerate the secret, the new plaintext secret is shown once for that regeneration event

​
Regenerating The Secret

If a secret is lost or exposed, regenerate it from the dashboard.
  • a new plaintext client_secret is generated
  • the old secret stops working immediately
  • every service using the old secret must be updated
Store the client_secret in your own secret manager. Treat it like any other backend credential.
Last modified on April 1, 2026