Sandbox & test keys
Get a test API key in about a minute, with no contract and no KYB. The sandbox exposes the same public operations against synthetic data.
The sandbox lets an engineer try the public Sender API before any contract
or know-your-business check. You verify an email, sign in to the portal, mint a
kpk_test_ key, and call the same endpoints you would in production, only
against a separate, synthetic data plane where nothing is billed and no real
person is ever contacted.
A key's prefix selects the data plane. kpk_test_ keys are sandbox;
kpk_live_ keys are live. The two never share data. See
Environments for how the switch works.
Get a test key
Signup is self-serve, and it happens in the portal. It is not an API call: starting an organisation is an act of a person, and there is no credential to sign one with until it exists.
Sign up at workspace.keepable.co with your organisation's name and your work email. The name becomes your sandbox tenant's, and it is worth getting right; personal email domains are refused, because a sender account belongs to a business.
Open the link we email you. It is single-use and lapses 30 minutes after signup; if it does, sign up again and a fresh one is sent.
Set up a passkey, which is how you get back in afterwards. See Authentication for the sign-in paths.
Mint a kpk_test_ key from the dashboard, and send it as
Authorization: Bearer on every call.
You are signed in the moment the link is opened, before any contract and before any KYB. A session and a key are not interchangeable: a session signs a person in, a key signs a server in, and only the second one is what your integration holds.
Manage, rotate, and revoke the key in Workspace. Credential administration is not exposed to the credential itself.
What's different in the sandbox
The sandbox runs the same code as production, with every costly or irreversible side-effect mocked:
| Concern | Live | Sandbox |
|---|---|---|
| Identity / KYB verification | Real vendor lookup | Deterministic from the test document number (see below) |
| Email + delivery | Real recipient inbox | Synthetic recipients; nothing is sent to a real person |
| Seals | Production KMS key | Non-production key, tagged sandbox- and reported as not legally valid |
| Per-send charges | Debits your wallet | Free and unlimited |
| Data | Your real tenant data | A separate schema-set; sandbox can never read live data |
You do not need an approved tenant, an accepted agreement, or a funded wallet to use the sandbox. Those are only required to go live.
Magic test data
Verification outcomes are driven by the last digit of the document number you submit (a NIN for a person, a CAC registration number for a business), so you can exercise every branch on demand without a real identity:
| Last digit | Outcome |
|---|---|
0 | Rejected (verification fails) |
9 | Provider unavailable (use this to test your retry/pending handling) |
| anything else | Approved, with a synthetic Sandbox Tester identity |
An empty document number also approves, so a happy-path test that omits it still
succeeds. For example, a NIN of 12345678901 approves; 12345678900 is
rejected; 12345678909 returns provider-unavailable.
Next steps
- Run your first plan with your test key.
- When you're ready for production, follow Going live.
Errors
Every non-2xx response is an RFC 7807 problem document. Here is the full catalogue of problem types, what triggers each, and whether to retry.
Going live
Moving from the sandbox to production means clearing three gates (an approved KYB, an accepted Sender Agreement, and a funded prepaid wallet) before you can mint a live key.