Test and live data
How sk_test_ and sk_live_ API keys keep sandbox data and production data completely separate.
ClientSphere keeps a sandbox alongside your production data. It is not a separate account or a second environment to provision — it is the same workspace, with its own set of records that your real customers never see.
Which one a request touches is decided entirely by the API key.
One key, one side
A key is created as either test or live and stays that way:
| Prefix | Reads and writes |
|---|---|
sk_test_ | Sandbox data |
sk_live_ | Production data |
There is no per-request override — no header, no query parameter. A key cannot reach across, which is the point: an integration pointed at a test key cannot email a real customer or delete a real account, however wrong its logic is.
The prefix must match the key's mode, and the API rejects a mismatch with 401
and INVALID_KEY.
Working with both
The usual arrangement is a sk_test_ key in local development, CI and staging,
and a sk_live_ key only in production, supplied as a secret at deploy time.
Because the two never mix, you can run a full integration suite against the
sandbox as often as you like.
Records created with a test key are only ever visible to test keys. If a record you just created seems to have vanished, the most common cause is creating it with one key and reading it with the other.
What is shared
Configuration belongs to the workspace, not to one side: your users, roles, and the API keys themselves are the same for both. It is the business records — accounts, contacts, opportunities, leads, messages — that are separated.