Test and live separation

Every application is registered as either test or live, and every API key inherits the environment of the application it is bound to (a reporting-scope key, which is not bound to one application, carries its own environment instead — see API keys).

environment is disclosure, never a pricing input

This is the one fact to internalize before building anything environment-aware:

A test application charges the authorizing user's standard credit and the owning business's premium money exactly as a live one does. The marker warns the user that the application is unpublished, not that its calls are free.

There is no simulated mode, no discounted rate, and no separate credit pool for test. A call made under a test application is billed identically to one made under a live application. environment exists so the authorization consent screen can show the user a visible marker before they grant access to an application that has not been published — never so your own code can branch on it to skip a charge or use a cheaper model.

What this means for your integration

• Never gate providerOptions.enlitt.charge on environment — every premium call declares its real charge regardless of which environment the authenticating key or application belongs to.
• Never word a test-environment notice, in your own UI or documentation, as "free," "simulated," or "no charge." If you surface the environment to your own users at all, describe it as unpublished, not free.
• Use test applications and keys for integration and staging work where you want a visibly separate application identity — for example, so a mis-scoped key is obviously wrong in your own logs — not as a way to avoid being charged.

Keeping keys and applications aligned

A key created for a live application cannot be used to authenticate calls you intend to attribute to a test application, and vice versa: the environment is fixed at creation and is part of the key's own metadata (see API keys). If your deployment pipeline promotes an application from test to live, issue it a new live-scoped key rather than reusing the test one — there is no in-place environment change on an existing key.