Test mode vs live mode

Test and live mode are separated per deployment. Each Strimz deployment runs in one mode: the sandbox runs on Arc testnet and accepts test keys only, and the live deployment runs on Arc mainnet and accepts live keys only. Each has its own contracts, RPC, scheduler and agent. Within the database, every resource carries a mode column. A test-mode call cannot settle a real payment, and there is no "promote to live" step that migrates test data over.

Live mode opens when Strimz runs on Arc mainnet. Until then, live keys can't be created.

Why the separation is so strict

Plenty of billing incidents trace back to one mistake: someone thought they were hitting test, but they were hitting prod. A key of the wrong mode is refused with 403 mode_unavailable, so a test key can't touch live data. When you're ready for production, you swap sk_test_ for sk_live_ and the rest of your code stays as-is.

What's different between modes

Every resource (Subscription, Transaction, WebhookDelivery, and so on) carries a mode column. The dashboard uses it to filter what you see. The scheduler uses it too: a scheduler instance running in test mode will only ever pick up test-mode subscriptions, and the same is true for live.

Switching modes

In your code, you switch modes by changing the API key. The same SDK client works for both:

import { StrimzClient } from '@strimz/sdk'
 
const strimzTest = new StrimzClient({ apiKey: process.env.STRIMZ_TEST_KEY! })
const strimzLive = new StrimzClient({ apiKey: process.env.STRIMZ_LIVE_KEY! })

In the dashboard, there's a toggle in the topbar. Switching it doesn't migrate anything. It only filters the data shown to that mode.

Webhooks per mode

Webhook endpoints are scoped to a single mode at creation. An endpoint with mode: 'test' only receives test events; the same URL can be registered twice (once per mode) if you want. The signing secret is per-endpoint-row, so test and live signatures are different.

Identity

Your merchant identity (business name, payout address, onboarding details) is shared across modes on purpose. There is no second onboarding to finish before going live. The transactional resources (sessions, subscriptions, refunds, deliveries, invoices) stay mode-segregated.