Auth Applications

Learn how Prelude Auth applications work.

Application Isolation

In Prelude Auth, all operations are scoped and isolated at the application level: data and operations for one application cannot affect or access another application’s.

To create a new application, contact us .

Multiple Applications

Each Prelude customer can have multiple applications, allowing you to:

• Separate different environments (development, staging, production)
• Isolate different products or services within your organization
• Create dedicated applications for specific use cases

Application IDs

Each application is identified by a unique Application ID (appID), which is the namespace for all resources and operations:

• API Endpoints: Most API paths include the appID (e.g., /v2/session/apps/{appID}/users)
• Webhooks: Event notifications are configured per-application
• Data Storage: All user data is partitioned by application ID

Benefits

• Multi-tenancy: Manage multiple environments with complete data separation
• Security: Prevents cross-application data access
• Organization: Clearly separates resources between different applications

When using Prelude Auth, you’ll need to use your assigned application ID consistently to ensure proper resource access.

Token Lifetimes

Each application has its own access and refresh token lifetimes, and they apply in both dev and prod mode:

• Access token: how long an access token stays valid before the frontend SDK has to refresh it. Between 60 and 86,400 seconds (24 hours). It is also the lifetime of the tokens issued by the client credentials flow.
• Refresh token: how long a refresh token, and so the session it belongs to, stays valid. Between 300 and 31,536,000 seconds (1 year), and never shorter than the access token lifetime.

Read them with GET /v2/session/apps/{appID}/config/tokens and change them with PUT /v2/session/apps/{appID}/config/tokens:

curl --request PUT \
  --url https://api.prelude.dev/v2/session/apps/{appID}/config/tokens \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '{
    "access_token_ttl": 900,
    "refresh_token_ttl": 2592000
  }'

Both fields are optional, so you can change one without sending the other. The new lifetimes apply to the tokens issued after the call: tokens already issued keep the lifetime they were signed with.

A longer refresh token lifetime takes full effect one refresh later. A session that already refreshed at least once keeps the expiry of the refresh token before the current one, so a session left idle past that earlier expiry ends even though its refresh token is still valid. Every session that refreshes within the previous lifetime gets the new one. A shorter lifetime applies right away, because the refresh token then expires first.