SANDBOX

Test in the sandbox

Submitting a draft moves it to SANDBOX and provisions it against a reserved, synthetic tenant with fake employees, conversations, and usage — never a real company's data.

What the sandbox is

Any app that isn't APPROVED — draft, sandbox, submitted, or rejected — can only ever authenticate against the sandbox tenant. That check lives at authentication, not per-capability, so every inbound surface inherits it automatically, including ones added after your app ships.

Submit your draft

POST /partner-apps/developer/apps/{id}/submit/
curl -X POST \
  -H "Authorization: Bearer $DEV_TOKEN" \
  https://api.sunesix.com/partner-apps/developer/apps/42/submit/

Moves your app from DRAFT (or REJECTED, after a fix) to SANDBOX.

Mint a sandbox key

The raw key is shown exactly once — copy it now. Losing it isn't a recovery problem, it's a rotation: minting again immediately invalidates the old one.

POST /partner-apps/developer/apps/{id}/sandbox-key/
{
  "success": true,
  "data": { "api_key": "pak.42.7f3a9c1e8b6d4f2a..." }
}

Use this key to call the capability endpoints (/partner-apps/capabilities/...) or gateway inference (/partner-apps/ai/chat/) against sandbox data, and to exercise your own outbound endpoint if you're building a guardrail.

Sandbox confinement

One of the certification probes checks that no active key for your app exists outside the sandbox tenant. You won't hit this by accident — it exists to catch a key that somehow reached a real company before approval.

CapabilitiesCertification