Test and live applications

Choose test for an unpublished application and live for a published one. The consent screen tells users when an application is a test application.

Test calls consume real credits. Standard calls consume the user's standard allowance. Premium calls consume their premium credits and credit the business after settlement, just as live calls do. A test marker does not create simulated spending, a separate credit pool, or a discount.

Configure each deployment

• Register separate application identities and callback URLs for development and live use.
• Create an App key for the matching application. App keys inherit their application's environment.
• Keep each deployment's ENLITT_SECRET_KEY in its own server secret storage.
• Read-only keys carry their own environment because they are business-wide.
• Existing keys do not change environment in place; issue a matching key when moving to live use.

The test/live application marker is distinct from the Enlitt server host your integration targets. A test application alone does not switch SDK traffic to a staging host.

Target Enlitt staging

Enlitt staging is a separate deployment with its own accounts, applications, and keys. Credentials from one never work on the other. To build against it:

• npx enlitt setup --env staging writes ENLITT_BASE_URL to your env file. The SDK reads it for model calls (a baseUrl option passed in code wins over it).
• The login handlers do not read ENLITT_BASE_URL. Set enlittOrigin in CallbackConfig yourself, for example from your own environment variable. enlittApiOrigin defaults to it.
• Both must point at the same deployment as your client ID and secret key, or login and calls fail as unknown credentials.

For automated development checks, mock the model and billing calls locally. If you make a real integration call, plan for its credit and provider cost.