Claim codes
Address somebody you have a name for and nothing else. Keepable deposits the file and mints a single-use code; you hand it over on your own channel, and they redeem it in the app after verifying their NIN.
Sometimes you hold a name and no identifier. A walk-in customer, a beneficiary on a paper list, somebody whose email you were never given.
A claim is the answer. Keepable deposits the correspondence against the name you declare, mints a single-use code, and gives the code to you. Keepable never contacts the person, never sends them a link, and never learns how you reached them.
{
"kind": "letter",
"subject": "Your settlement statement",
"recipients": [
{ "addressing": { "type": "claim", "declared_name": "Ngozi Nwachukwu" },
"ref": "CUST-100439" }
]
}The model is a money transfer: a deposit plus a reference the recipient quotes. The deposit is real before the code is handed over, and the code is worthless without the person.
Redemption
The claimant enters the code inside the Keepable app, after verifying their NIN. Keepable then checks their NIMC-verified name against the name you declared. A code alone is not enough; a code held by somebody whose verified name does not match the declared one does not redeem.
That check is the whole security model, and it is why there are no links. A link in a message is a credential that travels: forwardable, screenshottable, phishable, and indistinguishable from the phishing that imitates it. A code that only works in the app, only after NIN verification, and only for the named person, is not.
Keepable will never send your recipients a link to claim something. If you are writing the message that carries the code, you can say so, and mean it.
Managing codes
GET /correspondence/{id}/claims
POST /correspondence/{id}/claims/{claim_id}/void
POST /correspondence/{id}/claims/{claim_id}/reissueA claim is awaiting, claimed, expired, or voided.
Void a code you think has gone astray. The deposit stays; the code stops working.
Reissue mints a replacement with a new expiry and voids the old one, which is what you want both when a code was never received and when you suspect one leaked. Rotating a live code is the same operation as replacing a lost one.
Every claim carries an expires_at. A deposit nobody can reclaim and nobody can
clear is not a feature, so there is no such thing as a claim without one.
Getting the codes to people
Export them, join them to your own records, and deliver on whatever channel you already use:
POST https://api.keepable.co/sender/v2/correspondence/cor_01J8ZQ4T/exports
Authorization: Bearer {{KEEPABLE_TOKEN}}
Content-Type: application/json
{ "kind": "claims" }The CSV leads with the person and then your reference for them, which is the only column that rejoins a code to a contact you hold. See Exports.
When a code is redeemed
claim.claimed fires with the claim (spent, no code value) and its ref, so
you can mark your own record without polling. claim.expired fires when one
lapses unredeemed, which is your signal to chase or reissue.
Recipients and reachability
How Keepable finds a person, what happens when nobody matches, and how to check an identifier before you send.
HTML and CSS
What a text/html mailpiece body may contain. The allowed tags, the inline-CSS property list, the kp-* branded blocks, and everything the sanitiser strips, so your branded mail renders the way you intend.