Keepable
Sender API

Environments

Two data planes behind one API, chosen entirely by your key's prefix. There are no separate hostnames and no separate accounts.

Keepable runs two isolated data planes:

  • Sandbox: synthetic data, mocked side-effects, free. Keys are kp_sandbox_.
  • Live: real recipients, real seals, billed. Keys are kp_live_.

The plane is chosen by the key prefix, nothing else. Base URL, endpoints, and request shapes are identical. To switch environments, switch the key.

# Sandbox
GET https://api.keepable.co/sender/v2/wallet
Authorization: Bearer kp_sandbox_...

###

# Live
GET https://api.keepable.co/sender/v2/wallet
Authorization: Bearer kp_live_...

Nothing else in the request says which plane you are on, and that is deliberate: a credential that says live alongside a header that says sandbox is a question no request should be able to ask, and the answer decides whether a real send gets billed.

Confirm which plane you are on

GET https://api.keepable.co/sender/v2/me
Authorization: Bearer {{KEEPABLE_TOKEN}}
{ "organization_id": "org_01J8ZQ4T", "plane": "sandbox", "tier": "standard", "approved": false }

What differs

ConcernSandboxLive
RecipientsSynthetic; nothing reaches a real personReal, NIN-verified people
SendsFreeDebit the prepaid wallet
Seals and covenantsProduced, verifiable within the planeProduced, publicly verifiable
KYB approvalNot requiredRequired before any send
Identity checksMockedReal, and metered

Ids never cross planes. A cor_... minted in sandbox does not resolve against a live key, and nothing you did in sandbox appears in a live list.

Sandbox is usable before approval, which is the point of it: you can build and test the entire integration while your KYB is still in the queue.

On this page