Sandbox Environment

When creating a new project, administrators choose whether the project should be created as a Sandbox or Production environment. This choice is fixed at project creation and cannot be changed later.

Sandbox is designed for setup, implementation, and validation, but its value goes beyond the initial launch phase. It gives developers a safe place to integrate the SDK, test triggers, forms, and events, and verify end-to-end behavior without affecting live production activity. It also gives product managers room to review flows, confirm experience details, and align teams before changes are exposed to real users.

This matters because teams often need to configure, test, and iterate not only during onboarding, but also as an ongoing part of product development. Sandbox helps you validate new events, forms, and behavior changes in a controlled environment without being charged too early in the integration process or testing directly in production.

Why Use Sandbox

• Avoid production usage charges during setup: Activity in Sandbox does not consume your standard usage allocation while your team is still integrating and validating the product experience.
• Support implementation and review workflows: Developers can test integrations confidently, while product managers can review the user journey before rollout.
• Keep tighter control over production access: Teams can allow developers to work freely in Sandbox while limiting Production access to product owners or product managers responsible for approving and publishing live experiences.
• Use it as an ongoing testing environment: Sandbox is useful for continuous validation, allowing teams to test new forms, events, and experience changes outside the live production environment.
• Reduce go-live risk: Sandbox makes it easier to catch setup issues, validate configurations, and confirm expected behavior before you create or use a Production project.

Rate Limits

Sandbox environments have lower rate limits than Production. This helps protect the platform while still providing enough capacity for testing and validation.

Refer to the Rate Limits page for the current limits and guidance.

Feature Limits Per Project

Sandbox projects have the following limits per project.

Choosing the Right Environment

Create a Sandbox project when your team needs a safe environment for integration work, validation, ongoing testing, and internal review. This is the right choice when developers are implementing or updating events, forms, and triggers, or when product managers want to verify the experience before exposing changes to live users.

Sandbox is also useful when you want different levels of access across teams. For example, product owners or product managers may retain control over Production, while developers are given access to Sandbox during implementation. This allows the team to build and validate confidently, while keeping the final production-ready forms under the control of the people responsible for launching them.

Create a Production project when the experience is ready for real users, live traffic, and production usage tracking.