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:

  1. 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.
  2. 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
    

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

SandboxProduction
PurposeFor testing and developmentFor live, real-world usage
DataSynthetic, mock data generated by Unified.toReal data from integrated services
IntegrationsCan be activated with mock credentialsRequires real credentials from third-party services
API CallsReturn synthetic dataInteract with actual third-party services
RiskNo risk of affecting real data or servicesCan affect real data and services
AuthorizationCan use any mock credentials and bypasses scopesRequires 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:

  1. Initial integration testing and exploration
  2. Developing and debugging your application without affecting real data
  3. Running automated tests that don't require real-world data
  4. Demonstrating functionality without needing access to actual third-party services

Best practices

  1. Clearly distinguish between your sandbox and production environments in your code and workflows.
  2. Use the sandbox environment for initial testing before moving to production.
  3. When seeking support or reporting issues, specify which environment you're working in.

Additional information

Are we missing anything? Let us know
Was this page helpful?