Sandbox vs. Production

Overview

Alloy's API offers two modes: Production (Live) and Sandbox. The API mode controls whether Alloy makes live calls to third-party data vendors when running an Evaluation or Journey Application. Production mode invokes calls to third-party vendors and can incur charges. Sandbox makes no vendor calls, so you can test your integration without incurring additional charges.

It's important to understand that Alloy's Sandbox and Production API modes are not two separate environments. They are per-request processing modes only — Alloy does not enforce a data boundary. Most records in Alloy, including Entities, live in a single shared data store for your account, regardless of the mode used to create or update them. Because of this, any external identifiers you send to Alloy must not overlap between test and production systems.

How it Works

You can specify the API mode to use in the Base URL of your API requests:

Note: Some clients, including those based outside the United States, have custom base URLs specific to their account which differ from the primary base URLs above. Your implementation team will provide the appropriate base URLs if this applies to you.

Alternatively, you can also use the Production mode Base URL on all requests and pass the alloy-sandbox: true header dynamically to route the request to Sandbox. This is equivalent to using the Sandbox Base URL.

Authentication is the same for both modes within an Alloy account, so you do not need separate API keys for each mode.

Data Separation

Many Alloy record types are mode-agnostic within your account, and do not carry a Sandbox or Production association with them. Mode-agnostic record types include:

• Entities (person and business)
• Bank Accounts and External Accounts
• Transactions
• Devices

Some record types, including Evaluations and Journey Applications, do carry a Sandbox/Production association, but still exist within the same data store for your account.

Because the data store for your Alloy account is shared, any external identifier you send in Sandbox refers to the same record as that identifier sent in Production. If your test and production systems can generate the same identifier for different real-world things, sending both to Alloy will cause them to collide, mixing or overwriting data across your test and live use.

There are legitimate reasons to run both modes against the same Entity during testing, such as running against Alloy's example data in Sandbox while also testing a vendor's own test environment in Production. This is supported by design, and it is why you must manage identifiers deliberately rather than relying on the API mode to keep data apart.

Preventing Collisions

Keeping test and production data separate is your responsibility. When assigning identifiers, there are two common approaches to preventing collisions:

1. Use collision-resistant identifiers (recommended in all cases). Unique identifiers that are unlikely to overlap, such as UUIDs, make accidental collisions between your test and production systems very unlikely. For Entities, a strong identifier is stable, unique per person or business, and tied to a verified or authenticated identity. See External Entity ID Best Practices.

2. Prefix test identifiers. If you cannot guarantee collision-resistant identifiers, prepend a consistent marker such as TEST- or SBX- to the identifiers you submit for testing. This keeps test records programmatically separate from production records while remaining easy to trace.