Sandbox environment
The sandbox environment is a controlled, isolated testing space provided by Unified.to. It allows developers to activate integrations, create connections, and make API calls without interacting with real third-party services or affecting production data.
Key points to understand about the sandbox environment:
- It is specific to Unified.to and separate from any sandbox accounts you might have with third-party service providers.
- All API calls made in the sandbox environment return synthetic, mock data.
- At no point do you communicate with actual third-party providers when using the sandbox environment.
Using the sandbox environment
There are two ways to use the sandbox environment:
- From the web app:
- On app.unified.to, in the top right corner of the page, click on the Env dropdown.
- Select Sandbox from the options.
- When calling the Core API:
- When calling the Unified Core API e.g. to query integrations or generate an authorization URL, include
env=Sandbox
in the query parameters. For example:
https://api.unified.to/unified/integration/auth/{workspaceId}/{integration}?env=Sandbox
- When calling the Unified Core API e.g. to query integrations or generate an authorization URL, include
API reference: Core API overview
Note: If you use the Core API and do not specify env
, we will default to using the environment that is currently active on app.unified.to. As a best practice, be explicit about the environment you want to use when working with this API.
Sandbox vs Production environments
Sandbox | Production | |
---|---|---|
Purpose | For testing and development | For live, real-world usage |
Data | Synthetic, mock data generated by Unified.to | Real data from integrated services |
Integrations | Can be activated with mock credentials | Requires real credentials from third-party services |
API Calls | Return synthetic data | Interact with actual third-party services |
Risk | No risk of affecting real data or services | Can affect real data and services |
Authorization | Can use any mock credentials and bypasses scopes | Requires valid credentials and correct scopes |
Note: Production environment refers to any non-sandbox environment.
Key considerations about the sandbox environment
Synthetic data generation
- Mock data is generated when you activate an integration in the Sandbox environment.
- If you deactivate and reactivate an integration, it will be populated with new synthetic data.
Isolated testing environment
- Each activated integration and connection in the Sandbox has its own isolated set of synthetic data.
- This isolation allows you to test various scenarios without affecting real data or services.
Mock credentials
- In the sandbox environment, you can use any mock values for OAuth client IDs, secrets, API tokens, and other credentials.
- When creating a connection for an integration in the sandbox environment, you can also use any mock values when asked for them.
Integration-specific environments vs. Unified.to Sandbox
An important distinction to be aware of:
- Some integrations allow you to choose an "API region / environment" when activating them. This refers to that specific API provider's environment, not Unified.to's environment.
- Choosing "Sandbox" when activating an integration this way is not the same as using the Unified.to sandbox environment.
Environment-specific integrations and connections
- Activated integrations are tied to the active environment at the time of their activation.
- If you activate an integration (e.g., HubSpot) in the sandbox environment, it won't be available in the production environment, and vice versa.
- Similarly, a connection created for an integration in the sandbox environment will only return synthetic mock data and won't be accessible in the production environment.
When to use the sandbox environment
The Sandbox environment is ideal for:
- Initial integration testing and exploration
- Developing and debugging your application without affecting real data
- Running automated tests that don't require real-world data
- Demonstrating functionality without needing access to actual third-party services
Best practices
- Clearly distinguish between your sandbox and production environments in your code and workflows.
- Use the sandbox environment for initial testing before moving to production.
- When seeking support or reporting issues, specify which environment you're working in.
Additional information
- Tutorial: Build a simple Javascript app that calls the Unified API
- See how to build an app entirely in the sandbox environment