Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.trueparser.com/llms.txt

Use this file to discover all available pages before exploring further.

This page covers tenant application setup in the dashboard. Tenant apps are confidential clients for backend services and the Demo UI. They are not intended for browser-only clients.
An app can issue tokens without a plan, but the token will not include the entitlements claim. If the app is assigned a retired plan, token issuance is blocked.
App limits are tenant-scoped. If you need a higher app limit, contact support.

​
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 can have optional S3-compatible storage settings
  • 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 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.

​
Optional Storage Configuration

Some tenants connect their own S3-compatible storage backend to an app.
  • supported providers include AWS S3, Tigris, Cloudflare R2, MinIO, and Backblaze B2
  • the storage config stores access key, secret key, bucket name, and optional endpoint or region
  • if no custom storage is configured, the platform uses managed storage
  • the platform uses the stored credentials on your behalf
Your application still interacts with the platform API. It does not talk to the underlying bucket directly.

​
What Gets Stored On The App

In addition to the OpenIddict client record, the app stores tenant-specific metadata used 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 28, 2026