Sandbox & environments
The environment lives on the key, not in your configuration.
Sandbox & environments
Vortex has two environments, sandbox and production, and the credential
decides which one you are talking to: vp_test_ keys can only ever act on
sandbox data, vp_live_ keys only on production.
Why the key, not a setting
Most providers make environment a piece of configuration — a base URL, an
environment: "sandbox" constructor option, a dashboard toggle. Configuration
can drift from the credential: the classic failure is a production key combined
with a sandbox flag someone forgot to flip, or the reverse, discovered during a
launch.
Vortex removes the failure mode instead of documenting it. The environment is derived from the key on every request, server-side. There is nothing to set, so there is nothing to set wrong:
import { createVortex } from "@vortex-api/vortex/2026-08";
// Sandbox — because the key says so.
const vortex = createVortex({ apiKey: "vp_test_..." });
// Production — same code, different credential.
const live = createVortex({ apiKey: "vp_live_..." });Requests still carry an explicit environment field on bodies and query
strings. That is deliberate redundancy, not configuration: the API rejects
a request whose stated environment disagrees with the key’s, which turns
“wrong environment” from a silent data bug into an immediate 4xx.
What sandbox is
- A full copy of the API surface — every route, the same contracts.
- Real provider-side test rails behind it: charges, settlements, and payouts move through the same lifecycle they do in production, on test money.
- Yours immediately at signup. Production keys are issued after account activation.
What sandbox is not
- Not rate-limit free — keys are rate limited in both environments, so load behavior is representative.
- Not a mock. Slow settlement windows and asynchronous webhooks behave like the real thing, because they are the real machinery.