Sandbox Environments

Sandbox environments let you build and test your licensing integration in isolation from production. Each account has one production environment and one or more sandbox environments; how many depends on your plan. Everything you create in a sandbox stays in that sandbox, so your developers can experiment freely without polluting production data or metrics.

What a sandbox isolates

Each environment holds its own independent copy of your licensing data:

• Products, license templates, licenses, activations, and trial activations.
• Users, organizations, features, Entitlement Sets, and meter attributes.
• Releases and release files.
• Webhooks, automated email templates, and personal access tokens.

Names are independent per environment, so a sandbox can mirror your production setup: the same product names, feature names, and even user emails can exist in each environment without conflict.

Account-level settings are shared across the whole account and can be changed only from the production environment: team members, roles, SSO settings, sending domains, billing, and sandbox environment management itself.

Creating a sandbox

Go to the Settings -> Sandbox Environments page in the admin portal and click Create. The number of sandbox environments included depends on your plan.

To switch between environments, use the environment switcher in the top-right corner of the admin portal. All pages then show the selected environment's data.

Testing your app against a sandbox

The Product.dat file identifies the environment it was downloaded from. To point your app at a sandbox, switch to the sandbox, create a product there, and use that product's Product.dat and product ID in your app. LexActivator and LexFloatClient then work against the sandbox automatically; no code changes or special configuration are needed. License keys, users, and trials from the sandbox behave exactly as they would in production.

To use the Web API against a sandbox, create a personal access token while working inside the sandbox; access tokens are scoped to the environment they were created in.

Webhooks and automated emails are also configured per environment, so you can test your event-driven flows end to end without touching production integrations or emailing real customers.

Restricting team members to a sandbox

Team members with the admin or super admin role have access to all environments. On plans that include custom roles, you can restrict a team member with a custom role to specific environments by selecting them in the Environments field when inviting or editing the team member. This lets you, for example, confine a developer or an external contractor to a sandbox, keeping production data out of reach.

Sandbox limits

Sandboxes have small, fixed resource limits that do not depend on your plan; they are meant for testing, not production workloads. Your usage against these limits is shown on the sandbox's overview page. Activations in a sandbox never trigger plan upgrades. If your testing needs higher limits, contact us through the contact page.

Going to production

When your integration is ready to ship:

Then walk through the Launch Checklist before shipping to real customers.