Skip to main content

Environments

Physical and logical environments in the Trust Platform — Sandbox vs. Production and Staging vs. Live​

The Trust Platform has two dimensions of environment separation:

DimensionValuesHow it appears
PhysicalSandbox vs. ProductionTLD in the hostname (.sx / .io) — determines which Studio, API, authentication server, and documentation hub you use
LogicalStaging vs. LivePath parameter in every API request; staging / live labels on flow deployments and API credentials in Studio

These two dimensions are independent, giving four combinations:

staginglive
Sandbox (.sx)Sandbox Studio, API, Auth, Docs + staging credentials and flow deploymentsSandbox Studio, API, Auth, Docs + live credentials and flow deployments
Production (.io)Production Studio, API, Auth, Docs + staging credentials and flow deploymentsProduction Studio, API, Auth, Docs + live credentials and flow deployments

Sandbox vs. Production​

The Trust Platform has two physical environments: Sandbox (.sx) and Production (.io). Every service — Studio, the API, the authentication server, and the documentation hub — has a separate hostname for each environment, with completely separate databases and credentials.

info

The difference between the two environments is felt most strongly in Studio. Studio is where the two environments diverge: feature availability, visible step types, and platform behaviour can differ between Sandbox and Production.

The API, authentication server, and documentation hub each have separate Sandbox and Production deployments, but they are functionally equivalent — the same capabilities are available in both.

Studio​

Sandbox​

Studio Sandbox is where you evaluate the platform and build your flows before signing a contract and going live. It is not a mirror of Production — features, step types, and behaviour may differ due to feature flags and environment configuration. Do not treat it as a staging replica of Production.

Studio Sandbox shows step types that are deprecated or preview / alpha that are not available in Studio Production.

tip

Plan your flows based on stable step versions — building around preview or deprecated steps in Sandbox can mean significant rework when moving to Production.

Production​

This is where live customer sessions happen.

TopicWhat this means
Step typesPreview and deprecated step types (visible in Sandbox) are hidden in the Production Flow Editor.
Recreating Sandbox workEverything must be recreated from scratch in Production: (1) Third-party credentials, (2) IDnow services credentials, (3) Step configuration, (4) Flows.
API credentialsYou must create a new API Client for your Production organisation. See Staging vs. Live below.

API​

Use the Sandbox API to develop and test your integration. The Sandbox and Production APIs are functionally equivalent — the same endpoints and capabilities are available in both. They have separate deployments and separate credentials, but no feature differences.

warning

API credentials are scoped to a specific organisation in a specific environment Sandbox credentials do not work against the Production API.

tip

Before going live, create a new API Client in Studio Production and update all environment-specific values: the API base URL, the authentication endpoint, and any webhook configuration.

Documentation hub​

The documentation hub follows the same split, but the difference is minor. The Sandbox docs hub may include step types that are in preview or not yet available in Production; everything else is identical.

Staging vs. Live​

Within each physical environment (Sandbox and Production alike), the platform has two logical environments: staging and live. These are independent deployment slots for your flows — you can publish different versions of a flow to each one, and they share nothing.

The logical environment is specified in three places:

  1. On the flow deploments - for each flow, a version can be deployed in staging environment, in live environment, or one in both environments.
  2. In Webhooks for flows - for each flow, you can subscribe to events for the version of the flow that's deployed to staging, live or both.
  3. On the API client — when you create an API client in Studio under Settings → API Clients, you choose which logical environment it belongs to. An API client is permanently scoped to that environment and cannot be used against the other.
  4. In the API endpoint path — every request that targets a session or a flow deployment includes staging or live in the URL path.

Flow deployments​

A flow version must be explicitly published to a logical environment before it can receive sessions. Each logical environment holds at most one active deployment per flow at a time — publishing a new version replaces the current one. staging and live deployments are completely independent: you can promote a new version to staging without affecting what is running in live.

Example: Let's say you have created a flow called "KYC: enduser onboarding", and let's say you have v2 in staging and v5 in live.

  • When using live as the {environment}-parameter for API calls, you will be interacting with v5 of the flow.
  • When using staging as the {environment}-parameter for API calls, you will be interacting with v2 of the flow.
warning

Deploying a new version of a flow to staging and/or live replaces the current one without deleting the old deployment history.

Credentials and webhooks​

API clients and webhooks are also scoped per logical environment. A credential or webhook configured for staging has no effect in live, and vice versa. When going live, recreate all credentials and webhook subscriptions under the live environment.

StagingLive
Typical useIntegration testing and QAReal end-user sessions
API path/api/v1/flows/{flowId}/staging//api/v1/flows/{flowId}/live/
API client scopeAn API client created for staging can only access staging flows and sessionsAn API client created for live can only access live flows and sessions