What sandbox gives you
- A faithful copy of the production API, with the same encryption and the same enclaves
- Lower rate limits to protect shared infrastructure
- Test data that resets on request — talk to us if you want a clean slate
Scenarios to cover
Here’s the test matrix we recommend partners walk through before going live.Happy path
1
Assign a key
Call
POST /v1/partner/keys against the sandbox base URL. Confirm the key appears in your audit log.2
Encrypt and store
Encrypt a small test payload client-side with the public key (RSA-OAEP, SHA-256), then call
POST /v1/partner/secure/data with the ciphertext and plaintext checksum.3
Upload a file
Call
POST /v1/partner/secure/file with a small encrypted binary. Confirm you receive a backup_id.4
Confirm the audit trail
Verify each backup packages appear in the CoinCover Control log with the right
customer_id and package_id.5
Trigger a sandbox recovery
Recoveries run through CoinCover Control. Coordinate with your account manager to walk a sandbox recovery end-to-end before production.
Failure paths — Partner Key Service
These are the API-side failures most worth rehearsing.Failure paths — recovery flow
Recoveries run through CoinCover Control — a human-driven UI, not an API. When a recovery is approved, the recovery material is delivered to the authoriser as a GPG-encrypted secure download. There’s no programmatic surface here for partners to integrate against; you’re testing the end-to-end operational path with us. Coordinate with your account manager to walk these scenarios end-to-end in sandbox before production:- Authoriser not on the ACL — the request from an unauthorised identity should be refused
- Authoriser’s GPG key is wrong or missing — they receive a payload they can’t decrypt; confirm your runbook handles this without exposing plaintext
- Identity verification doesn’t complete in time — the recovery should expire cleanly, not hang
- Stale key reference — recovery against a rotated or superseded key should be rejected