Skip to main content
VEXiON cards gives you two environments: production, where your real customers and balances live, and a sandbox, where you build and test. They expose the same endpoints and return the same responses. The sandbox receives each release before production, so it can be briefly ahead; the Changelog says when a change reaches production. The two have separate databases, so nothing you do in the sandbox reaches a real customer. Moving from one to the other means changing two values: the base URL and the API key. The API Reference playground carries both: pick the environment from the server dropdown above any endpoint.

A sandbox key only ever resolves inside the sandbox lane. There is no path from a vxn_test_sk_ key to production data, and no path from a vxn_sk_ key to sandbox data.

Sandbox

Key prefix vxn_test_sk_. Requests only ever reach sandbox data, no matter which endpoint you call.

Production

Key prefix vxn_sk_. Requests only ever reach production data, no matter which endpoint you call.

The two environments

Because the key prefix differs, you can tell at a glance which environment a key belongs to, including in your own configuration and logs. A key is only ever valid in the environment that issued it.

Getting sandbox access

Sandbox access is provisioned per partner. Contact us and we will create a sandbox organization for you and issue a vxn_test_sk_ key. The key is what grants access; without one the sandbox host will not authenticate you. Dashboard keys (vxn_sk_) are production keys and do not work in the sandbox. Your production keys stay where they are, at Dashboard → Settings → Developer.

Working in the sandbox

The sandbox works like production, which is the point: what you see while building is what you get in production. Effects are real within the sandbox, so a stamp award moves a sandbox balance and a pass pushes to a wallet. Email and SMS are limited, so a test never reaches a real customer.

Email, invitations and SMS in the sandbox

  • Email reaches only your organization’s own people. That is the owner, team members we added for you, their +aliases (for example anna+test1@yourcompany.com) and your company domain, if we set one up for you.
    • An explicit send to any other address answers 422 recipient_not_allowed_in_sandbox. This covers POST /v1/customers/{id}/deliver, team invitations and the dashboard resend and one-time code.
    • POST /v1/customers with deliver stays 201 and reports last_delivery as { status: "failed", error: "recipient_not_allowed_in_sandbox: ..." }. The same applies to SMS with sms_not_available_in_sandbox.
    • Automatic emails (automations, reports) to anyone else are simply not sent.
  • Team members: only the owner’s +aliases and your company domain, at most 5 people including the owner. Ask us to add more people.
  • Invoices reach your billing email only when it belongs to your own people (for example the owner address).
  • SMS is never sent. channel: "sms" and channel: "both" on a delivery answer sms_not_available_in_sandbox. Test delivery with channel: "email". SMS works in production.
That makes a few habits worth adopting from the start.
1

Test with your own people

When you exercise a flow that emails or pushes a pass, use an address of your own people (the owner or a +alias) or your own device as the recipient. You see exactly what a customer would receive.
2

Tag the data your tests create

Pass a recognizable external_id (for example qa-run-4821-cus-1) on the customers and transactions your tests create, so you can find them later and so a re-run never double-creates.
3

Scope each key to what it needs

Give a key only the scopes it uses. Each endpoint page in the API reference names the scope it needs. This is good practice in both environments.
4

Point webhooks at an endpoint you control

Register a webhook endpoint on a tunnel or a test receiver, verify the signature, and watch real events arrive. Delivery, signing and retries behave the same in both environments.

Idempotency

Every mutating call accepts an Idempotency-Key. Reusing the same key on a retry returns the original result instead of performing the operation twice, so a network retry of a stamp award never awards twice. Wire it in from the start and it protects you in both environments. See Idempotency.

Going live

1

Swap the base URL

Point your client at the production base URL.
2

Swap the key

Replace your vxn_test_sk_ key with a production vxn_sk_ key from the dashboard.
3

Re-create what production needs

Sandbox data stays in the sandbox. Create your production cards and webhook endpoints the same way your integration created them in the sandbox. Set up locations in the dashboard.
Request shapes, responses and webhook payloads are the same, because you built against the same API the whole time.
Treat a production vxn_sk_ key as live access from its first request. Store keys in a secret manager, never in client-side code or source control.