---
updatedAt: 2026-10-14T14:18:11.000Z
agentTools:
  projectIndex: https://docs.cybrid.xyz/llms.txt
---

# Sandbox vs. Production

How does the sandbox environment differ from the production environment?

The Cybrid sandbox provides a safe and realistic environment for testing your integration without affecting live data or funds. This guide outlines the key differences between the sandbox and production environments.

## Fiat Transfers

All fiat transfers in the `sandbox` environment are simulated. No real funds are ever pulled from or sent to actual bank accounts.

* **Deposits**: Simulated deposits succeed almost instantaneously.
* **Withdrawals**: Simulated withdrawals also succeed almost instantaneously.

### Automatic Funding

To streamline testing, the sandbox automatically fronts funds for operations that would otherwise fail due to a non-sufficient funds (NSF) error. This removes the need to perform deposits before experimenting with trades and withdrawals.

Operations that are auto-funded include:

* Book transfers
* Crypto withdrawals
* Funding transfers
* Trade executions
* Platform and bank fees

To test a real NSF scenario, use the `expected_error` parameter in your request. This bypasses the auto-funding mechanism for that specific transaction.

```http Request
POST /api/transfers
{
  "quote_guid": "...",
  "expected_error": "non_sufficient_funds"
}
```

## Crypto Transfers

### Deposits

Crypto deposits in the `sandbox` are performed on-chain using testnets. This allows you to test real-world deposit scenarios, and your Cybrid account balances will update to reflect the deposit.

> ℹ️ Testnet Information
>
> * **BTC**: Testnet3
> * **ETH**: Sepolia
> * **USDC on Ethereum**: Sepolia
> * **SOL**: Testnet
> * **USDC on SOL**: Testnet
> * **MATIC**: Amoy
> * **XLM**: Testnet
> * **USDC on Stellar**: Testnet
> * **USDT on Tron**: Testnet

### Withdrawals

Crypto withdrawals are simulated and are not performed on-chain. They succeed almost instantaneously. The sandbox also fronts funds for crypto withdrawals if an account has an insufficient balance.

Our liquidity providers do not support buy/sell operations on testnets, so trades cannot be settled on-chain. Allowing withdrawals of testnet funds from trades would create a confusing user experience, as the platform would show sufficient funds while the on-chain balance would be zero.

## Trades

Trades in the `sandbox` are simulated, meaning there is no actual on-chain movement of crypto or fiat. Trades execute against real-world market prices but do not involve liquidity providers.

* Trades reach the `executed` state and do not transition to `settling` or `completed`. Liquidity providers do not support trades on testnets, so the final on-chain settlement cannot be performed. Funds are still made available for downstream testing even though `platform_available` is not updated to reflect the trade.
* The sandbox fronts funds for trades if an account has an insufficient balance.

> ⚠️ Trade Quote Expiration
>
> Trade quote expiry is not configurable and can vary. Use the `expires_at` field on the quote response to determine when a quote expires.

### Testing Trade Failures

The `expected_error` parameter allows you to simulate trade failures in the `sandbox`.

```http Request
POST /api/trades
{
  "quote_guid": "...",
  "expected_error": "expired_quote"
}
```

Valid values for `expected_error` are `expired_quote` and `non_sufficient_funds`. This parameter is not permitted in the `production` environment.

## Identity Verifications

In the `sandbox`, you can integrate with an identity provider's sandbox API (e.g., Persona's sandbox) to simulate verification workflows.

### Testing Verification Outcomes

The `expected_behaviours` parameter allows you to simulate specific verification results without completing the full KYC/KYB process.

```http Request
POST /api/identity_verifications
{
  "type": "kyc",
  "method": "id_and_selfie",
  "customer_guid": "...",
  "expected_behaviours": ["passed_immediately"]
}
```

| Behavior             | Effect                                  |
| -------------------- | --------------------------------------- |
| `passed_immediately` | Forces immediate verification approval. |
| `failed_immediately` | Forces immediate verification failure.  |
| `tax_id_not_checked` | Simulates a tax ID verification bypass. |

> ℹ️ KYB review in the sandbox
>
> In the `sandbox`, the Cybrid compliance team does not review identity verifications for business customers (`kyb`). Instead, a KYB that goes through the Persona flow and goes to review is automatically approved about 1 minute later. In `production`, these are reviewed and approved by the Cybrid compliance team.
>
> To get a `verified` business customer without going through Persona, create the `business_registration` identity verification with `expected_behaviours: ["passed_immediately"]`. The verification is created already completed and skips Persona, so no `persona_inquiry_id` is returned and no business associate verifications are required.

## External Wallets

Wallet operations in the `sandbox` are simulated. Addresses are not validated on-chain, and no real blockchain transactions are executed.

## API Behavior

Several API parameters are available exclusively in the `sandbox` to help you simulate different states and errors. These are rejected in the `production` environment.

| Parameter             | Resource                        | Valid Values                                                     | Purpose                                      |
| --------------------- | ------------------------------- | ---------------------------------------------------------------- | -------------------------------------------- |
| `expected_error`      | Trades                          | `expired_quote`, `non_sufficient_funds`                          | Simulate trade failures.                     |
| `expected_state`      | Payment Instructions, Transfers | `pending`, `in_progress`, `completed`                            | Force specific outcomes.                     |
| `expected_behaviours` | Identity Verifications          | `passed_immediately`, `failed_immediately`, `tax_id_not_checked` | Control verification results.                |
| `expected_behaviours` | Transfers                       | `force_review`                                                   | Force a transfer into the `reviewing` state. |

## API Rate Limits

Cybrid uses rate limiting to safeguard the stability of core APIs. The default rate limiter allows up to **100 requests per IP address every 5 minutes**. If you think you might exceed these limits in most scenarios, using [webhooks](https://docs.cybrid.xyz/docs/webhooks) is an easy-to-use and effective way to receive event updates and helps you stay within the API rate limits.

## Activity Limits

Activity limits in the `sandbox` are different from `production`.

* **Production**: See our guide on [Limits and Minimums](https://docs.cybrid.xyz/docs/limits-and-minimums) for details on production limits for individual and business customers.
* **Sandbox**: Activity limits for both individual and business customers are set to $15,000 daily and $50,000 weekly.