Skip to main content

Sandbox Workspaces

A sandbox is a full shadow copy of your workspace where only the simulator can ever run. Build campaigns, wire journeys, call the API, break things — nothing reaches a real subscriber, nothing touches your quota or billing, and your live data is never involved.

Sandboxes are available on every plan, one per workspace.

What makes it safe​

The "nothing sends for real" guarantee is structural, enforced at two independent layers — neither is a setting anyone can flip:

  1. A sandbox cannot hold provider credentials. Uploading APNs keys, FCM service accounts, or any other real credential into a sandbox is refused by the platform.
  2. Delivery is forced to the simulator. Every job belonging to a sandbox routes to the simulator at dispatch, regardless of what the request asked for.

Either layer alone is sufficient; both would have to fail simultaneously for a sandbox to deliver anything real.

Creating and entering​

Settings → Sandbox workspace → Create sandbox (workspace owner only). Creation takes a few seconds and mirrors your owner/admin teammates into it, so it appears in everyone's workspace switcher with an unmistakable SANDBOX badge. While you're inside, a persistent amber banner reminds you that nothing here sends for real.

Via the API:

POST /api/v1/sandbox        → 201 { "tenant_id", "name", "slug", "provisioned" }
GET  /api/v1/sandbox        → the sandbox, or 404 when none exists

What's inside​

A sandbox opens populated, not empty:

  • Your channels, copied — same types and names (suffixed "(sandbox)"), active and usable, with no credentials behind them.
  • 50 synthetic subscribers (sandbox-user-01 … sandbox-user-50) with devices spread across your channel classes, varied attributes for filter and segment testing, and three ready-made lists.
  • 30 days of seeded engagement history with realistic, class-distinct open/tap rates — so analytics, best send hour, and smart channel rankings all have material from the first minute.

Everything is synthetic. Production data is never copied into a sandbox.

Your plan is inherited live from the parent workspace, so plan-gated features (smart channel, digest batching, optimal send time) are testable in the sandbox exactly as they'd behave live — and a plan change on the live workspace propagates.

Working in a sandbox​

  • Compose shows a single "Send (simulated)" action — there is no separate Simulate button because everything is simulated.
  • Runs land in History with the Simulated badge and full guardrail readouts, like any simulated send.
  • Server API keys minted inside a sandbox use the hober_test_ prefix, so a test key pasted into production config self-identifies. They authenticate only against the sandbox.
  • A sandbox has a generous daily job cap (simulation is free of provider cost, not of compute); hitting it returns 429 until the next UTC day.

Resetting​

Settings → Sandbox workspace → Reset sandbox (owner only, with a typed confirmation) wipes everything the sandbox accumulated — sends, journeys, segments, edited subscribers — and re-seeds the original synthetic data. The sandbox's identity survives: same tenant id, same memberships, same API keys.

POST /api/v1/sandbox/reset  → 200, idempotent (wipe-first, safe to re-run)

Promoting work out of the sandbox​

Templates you build in a sandbox can be copied to your live workspace: Templates → Copy to live on any template card (inside the sandbox), or via the API:

POST /api/v1/sandbox/promote/template/<template-id>
→ 201 { "template_id": "<live-copy-id>", "name": "Welcome flow (from sandbox)" }

The rules are deliberate and strict:

  • One-way, one pair. Promotion always flows from your current sandbox to its parent — the destination is never a parameter, and nothing ever copies into a sandbox from live.
  • Copy, never overwrite. The live workspace always gets a new template; a name collision gets a "(from sandbox)" suffix. Your live templates cannot be touched by a promotion.
  • Never auto-activates. A promoted template is inert until someone uses it in a live send — promotion can never cause delivery.
  • Admin-gated on the live side. You need an owner or admin role in the live workspace; being in the sandbox alone is not enough to write into live.

Only templates promote in v1. Journeys and in-app experiences built in a sandbox still need to be rebuilt by hand — they carry channel and segment references that don't transfer between workspaces yet.

Limits, honestly​

  • One sandbox per workspace, and a sandbox cannot have a sandbox.
  • Membership mirroring is point-in-time: owners/admins at creation get access; teammates added later must be invited from the sandbox's own Team page.
  • No production parity for provider quirks — the simulator never tells you whether a real APNs token would have bounced.
  • Promotion is templates-only — see above.

Simulate vs sandbox — which one?​

You want to…Use
Rehearse one send safely (audience, guardrails, arbitration)Simulate in your live workspace
Fire a single push at your own deviceTest send (defaults to simulate)
Experiment with journeys, segments, or API integration over daysSandbox
Let a teammate learn the product without riskSandbox