Confirm a money-movement instruction
Verifies the code sent to your registered confirmation contact and, once correct, hands the instruction off for execution. The response reflects the instruction status immediately after this call (confirmed) — poll GET /v1/transfers/:id for what happens next.
Authorization
partner-key In: header
Path Parameters
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/v1/confirmations/string" \ -H "Content-Type: application/json" \ -d '{ "code": "482913" }'{ "confirmationId": "df9f1e6a-0000-4000-8000-000000000030", "subjectType": "transfer", "subjectId": "bd9f1e6a-0000-4000-8000-000000000010", "status": "confirmed", "verifiedAt": "2026-09-11T00:02:00.000Z"}Resend the confirmation code POST
Re-issues the code on the shared escalating resend ladder. Refused while the previous code is still within its cooldown window.
Ask a payer to send you KES over M-PESA POST
Sends an STK Push prompt to the number you name. The payer approves it on their own handset with their PIN — there is no OTP for you to handle and no way for you to complete it on their behalf. The deposit lands in your own KES account, which is resolved from your verified business and is not something you can specify. This returns as soon as the prompt is out, so treat the response as pending: the completion signal is the credit.received webhook, and a prompt the payer declines or ignores produces no event at all. There is no idempotency key. A repeated call is a second prompt, and if the payer approves both then both deposits land and each raises its own credit.received.