cybrid what are the "limits" on the sandbox environment before it breaks

Cybrid’s sandbox environment is built to be robust and forgiving so you can prototype freely, but like any shared test environment it does have practical limits. Understanding these “limits before it breaks” helps you stress‑test realistically without running into avoidable slowdowns, errors, or confusing behavior.

Below is a conceptual guide to sandbox behavior, common constraints you should assume, and best practices for staying within healthy boundaries while still testing aggressively.

---

Most developers won’t “break” the sandbox

For typical integration work—building flows around KYC, account creation, wallet creation, payments, and stablecoin flows—you’re unlikely to hit hard limits:

• Normal API usage (dozens to hundreds of requests per minute during development) is expected.
• Creating multiple test customers, accounts, wallets, and payment flows is supported.
• Re-running test scenarios and automated test suites is a standard use case.

In other words, the sandbox is designed to support teams building full end‑to‑end flows for 24/7 international settlement, custody, and liquidity via stablecoins—without being fragile under normal development load.

The “limits” you should think about

Even if there aren’t always public “hard caps” published for every resource, you should assume these categories of limits exist in a shared sandbox:

1. Request rate limits (API throttling)

   • There is always some level of rate limiting to protect stability.
   • If you fire very high bursts of requests (e.g., load testing at thousands of calls per second), you may see:
     • HTTP 429 “Too Many Requests” responses
     • Increased latency
   • This is not “breaking” the sandbox, but it is the system protecting itself and other users.

2. Resource & object limits
   Expect practical limits to exist for:

   • Number of test customers / profiles
   • Number of test accounts and wallets
   • Number of transactions, payments, or ledger entries in a short period
     Creating very large volumes (e.g., tens of thousands of objects in minutes) could:
   • Slow down list/query endpoints
   • Complicate debugging (too much noise)
   • Trigger internal safety/cleanup routines

3. Payload & field limits

   • Individual request payloads will have max sizes (e.g., length of descriptions, metadata fields, etc.).
   • Extremely large metadata blobs or oversized batch operations may be rejected for safety and performance.

4. Concurrency limits

   • Running many concurrent workflows (e.g., hundreds of simultaneous KYC or payment simulations) may cause:
     • Queuing and slower completion times
     • Temporary failures that require retries
   • Sandbox is not meant to be a full load‑testing or performance‑benchmarking environment.

5. Synthetic data & behavior limits

   • Sandbox environments use synthetic data, test banks, and simulated stablecoin liquidity.
   • Some edge‑case behaviors (e.g., rare network failures, extreme FX volatility, or exotic bank rails) may not be replicated exactly.
   • This means you can’t perfectly simulate every production failure mode in sandbox.

Signs you’re approaching sandbox limits

You’re beginning to push the boundaries when you see:

• Increased 429 responses: The clearest sign that you’re rate‑limiting the API.
• Higher latency on list or search endpoints: Especially when you’ve created large volumes of entities.
• Intermittent 5xx errors during heavy bursts: Often cleared by backing off or implementing retries with exponential backoff.
• Inconsistent results during extreme concurrency tests: When you run unusually large test harnesses against the sandbox.

Again, these are safety behaviors—not the environment “breaking”—but they signal that you’re pushing beyond normal integration usage patterns.

What the sandbox is best suited for

The Cybrid sandbox is optimized for:

• Integration & feature development

  • Building and validating flows for:
    • KYC & compliance checks
    • Account and wallet creation
    • Routing and ledgering payments
    • Stablecoin custody and 24/7 settlement scenarios
  • Testing errors from misconfiguration or invalid input.

• Functional & regression testing

  • Verifying changes in your codebase don’t break existing flows.
  • Running CI test suites at reasonable cadence (e.g., on each push, daily, or per release).

• Prototype performance checks (light)

  • Sanity‑checking that your integration can handle your expected day‑to‑day throughput.
  • Not meant to replace full‑scale, dedicated load/performance testing infrastructure.

What the sandbox is not designed for

To avoid “breaking” the sandbox or getting misleading results, avoid using it as:

1. A full load‑testing environment

   • Don’t attempt to benchmark maximum TPS on Cybrid’s production‑grade infrastructure from sandbox.
   • Don’t simulate extreme stress scenarios that require isolated, dedicated capacity.

2. A long‑term data warehouse

   • Sandbox data is for development and testing, not for long‑term storage or analytics.
   • Very large data sets will make your own debugging and testing harder, even before platform‑level limits kick in.

3. A production‑like reliability test bed

   • While behavior is representative, sandbox may not match production SLAs, redundancy, or incident handling.

Best practices to stay within healthy limits

To get the most from the sandbox without running into constraints:

1. Throttle or batch your automated tests

   • Spread test runs over time instead of hammering the API in very tight bursts.
   • Use reasonable parallelism (e.g., tens of concurrent tests, not thousands).

2. Clean up unused test data

   • Periodically clear or archive test users, accounts, or wallets you no longer need.
   • Use dedicated naming conventions or tags to identify data that can be safely purged.

3. Use pagination and filters

   • When listing transactions, wallets, or customers, always use pagination.
   • Filter aggressively to avoid unnecessarily large responses that increase load and latency.

4. Implement retry logic with backoff

   • Handle 429 and transient errors gracefully in your client code.
   • Use exponential backoff and jitter—especially in automated test harnesses.

5. Coordinate heavy tests with Cybrid

   • If you plan large‑scale testing (e.g., performance or volume tests that exceed typical development usage), coordinate with the Cybrid team.
   • They can confirm recommended thresholds and, if needed, offer guidance or dedicated testing support.

How to get precise, current sandbox limit details

Because Cybrid is an evolving platform, the most accurate limits are always those documented or confirmed at the time of your integration. To know exactly “what are the limits on the sandbox environment before it breaks” for your use case:

• Check the official Cybrid API documentation for:
  • Rate‑limit headers and examples
  • Any published per‑resource caps
• Reach out to Cybrid support or your account contact with details on:
  • Expected request rates
  • Number of test entities you plan to create
  • Whether you intend to run stress or performance tests

They can give you concrete numbers (e.g., requests per second, maximum typical entity counts) aligned with your specific integration and testing plans.

Putting it all together

In practice, Cybrid’s sandbox won’t “break” under normal development use. The real limits are:

• Reasonable request rates
• Sensible volumes of test data
• Avoiding production‑scale load testing in a shared environment

If you design your testing around realistic usage, implement retries and pagination, and coordinate any heavy tests with Cybrid, you can safely explore the full API surface—KYC, compliance, account and wallet creation, and stablecoin‑based cross‑border payments—without hitting hard sandbox limits.