Skip to main content
Galactic Core ships with a built-in sandbox: a fully isolated test environment that lives inside the same API. There is no separate base URL and no separate account — you switch environments purely by which API key you authenticate with. This makes the sandbox ideal for local development, CI pipelines, and AI agents that need to safely exercise write endpoints (create orders, register customers, add to carts) without ever touching a merchant’s real data.

​
Test keys vs. live keys

The key prefix is the only thing that selects an environment. Every store has both pairs. The two never cross. A test key only ever reads and writes sandbox data; a live key only ever touches production. There is no flag to flip and no header to set — the environment follows the key automatically.
Every authenticated response carries a Tybrite-Environment: production | sandbox header, so you can always confirm which environment resolved for a request.

​
What is isolated

Transactional data you create through the API is stamped with the environment of the key that created it. That includes:
  • Orders
  • Customers
  • Carts and wishlists
  • Product reviews
  • Messaging conversations
  • Returns
A sandbox record is invisible to a live key, and vice versa — to the other environment, the record simply does not exist (a cross-environment lookup returns 404, never a hint that the record lives elsewhere). Catalog and reference data is shared. Products, categories, and promotions are read-as-is in both environments — a test key reads the merchant’s real catalog, so you can build and test a realistic storefront against actual products. It just gets no production transactional data tied to those reads: a test key sees only the orders, customers, and carts created in sandbox.
When you initialize a payment with a test key, the underlying payment provider is forced into test mode automatically — regardless of the store’s live payment settings. A sandbox checkout can never create a real charge.
A test key sees every provider and integration the merchant has configured, including ones still on test credentials. A sandbox checkout can therefore list providers labelled test or sandbox, which is what makes an integration testable before it is live. Live keys resolve the same configuration differently: a provider or integration holding test credentials is not offered to a real customer and is refused if requested directly — see Guardrails. The provider list a sandbox key returns is consequently a superset of the one a live key returns for the same store.

​
Sandbox data is invisible in the merchant’s app

Sandbox rows exist only for API testing. They never appear in the merchant’s admin dashboard, the storefront, reports, or anywhere in the product — so your test traffic can’t pollute a merchant’s numbers or clutter their order list.

​
Automatic cleanup

Sandbox data is automatically purged after 30 days, so a sandbox record is not a durable store — a test suite that needs particular data re-seeds it rather than assuming a previous run’s rows are still there. The purge can also be triggered on demand rather than waited for.
API keys are never auto-deleted. Only the transactional sandbox data (orders, customers, carts, reviews, messaging, etc.) is cleaned up. Your test keys remain valid until you remove them yourself.

​
Developer tools

Three operations control sandbox state directly. All require a secret test key (tybrite_sk_test_*), only ever affect your sandbox data, and are available via client.sandbox in the SDK (full reference: SandboxService).

​
Sandbox reset

Removes all sandbox test data in one call, ahead of the 30-day cleanup — a clean slate before a test run.

​
Time travel

Advances your sandbox by N days, so time-dependent behaviour resolves without a real wait: Galactic Core back-dates your sandbox data, elapsing abandoned-cart windows, releasing reserved stock, and rolling analytics forward.
The response’s not_shifted explains what is intentionally left alone — to test promotion or gift-card expiry, create one in sandbox with a near-future date.

​
Webhook replay

Re-sends a recorded sandbox webhook event to your endpoints without recreating the underlying order or customer, so a handler can be iterated on against the same payload.

​
How to use it

There is nothing to set up. Authenticate with a test key and you are in the sandbox. See the Authentication guide for the full key reference.
Build and test your entire integration with tybrite_sk_test_* keys, including in CI. When you’re ready to go live, swap to a tybrite_sk_live_* key — the right environment follows automatically, with no code changes.