01 · HMAC-SHA256
Zero plaintext codes
OTP codes are verified via HMAC-SHA256 bound to your account, environment and phone number. History logs [OTP masked].
Available · HMAC-SHA256 Hardened
KambaSMS / SMS + OTP
Transactional SMS and cryptographic OTP for +244.
Deliver critical notifications with your approved Sender ID or issue 6-digit OTP codes with HMAC-SHA256 verification, single-use locks and real-time DLR webhooks across Unitel, Movicel and Africell.
POST /otp/send1 CRÉDITO · VERIFY GRÁTIS
POST /otp/send
X-API-Key: kamba_live_...
Idempotency-Key: login-9f8c4b2a
{
"phone": "+244923000000"
}
→ 200 OK · otp_id: "9f8c...4b2a" · expires_in: 300History stores [OTP masked] · Never plaintext+244 E.164
01Enterprise security & limits
Engineered for critical verification and B2B operations.
Every OTP and transactional SMS passes through strict Sender ID validation, atomic credit reservation, cryptographic hashing and isolated rate limits.
02 · 5 MIN · 5 ATTEMPTS
Single-use & brute-force lock
Strict 5-minute expiry, transactional single-use consumption and immediate invalidation after 5 failed attempts.
03 · 60 SEND / 120 CHECK
Isolated per-account & function limits
Dedicated capacity of 60 sends/min and 120 checks/min per authenticated key, plus 3 OTP/hour protection per phone number.
04 · DLR · WEBHOOKS
End-to-end trace & signed DLR
Correlation across request_id, credit reservation and carrier delivery reports with HMAC-SHA256 signed webhooks.
Preview · placeholder video
See SMS and OTP in action.
Prepare your Sender ID, review required credits and track the sending outcome.
SMS and OTP
Sample- 01Prepare Sender ID
- 02Review message and credits
- 03Send and track
Temporary sample footage for reviewing the player. The product video will replace it.
02Choose the flow
SMS, OTP and Verify solve different parts of communication.
All three share the same credit balance (1 credit per accepted SMS segment, 0 credits for verification checks).
01 // SMS_DIRECT
Transactional SMS
You define the complete message content (up to 160 characters per GSM-7 segment) with your approved Sender ID.
Best for
Invoice confirmations, receipts, operational alerts and reminders.
POST /messages/send1 credit per accepted SMS segment
Explore02 // OTP_HMAC
Secure OTP (HMAC)
KambaSMS generates a cryptographic 6-digit code, stores only the HMAC-SHA256 hash and validates via /otp/verify.
Best for
Two-step login, operation validation and password recovery. For full second-factor management, see Authenticator.
POST /otp/send → /otp/verify1 credit on send · Verification 0 credits
Explore03 // VERIFY_SESSION
Kamba Verify
Atomic verification session with controlled resend (/verify/resend), single-use token and event history.
Best for
Account onboarding and flows requiring managed resend in two calls.
POST /verify/start → /verify/check1 credit per code sent · Free check
Explore03Contacts, lists and templates
Save contacts once. Reuse them when you need to communicate.
The dashboard lets you keep a private transactional contact book, organize recipients into lists and use them in individual or bulk sends. Managing contacts does not send messages or consume credits.
Manage contactsCreate or import
Add contacts individually or import a CSV with name, phone and optional business data.
Organize into lists
Group recipients by operation, service or transactional purpose for later reuse.
Use when sending
Choose one contact for an SMS or load an active list into Bulk. Blocked contacts are excluded.
04Reusable messages
Less repetition. A personal message for each contact.
Save confirmations, reminders and alerts as templates. Apply them in individual sending or Bulk and edit the draft before sending. Managing templates does not consume credits.
Segment calculation shows the exact credit cost before sending (160 GSM-7 characters per segment).
Manage templatesSaved template
Hello {{nome}}, your appointment is confirmed for {{data}}. Reference: {{referencia}}.
{{nome}}{{empresa}}{{data}}{{referencia}}Final preview · 1 segment
Hello Ana, your appointment is confirmed for tomorrow at 10:00. Reference: AG-204.
05Before the first send
A short setup, with clear responsibilities.
KambaSMS handles validation, routing and records. Your business remains responsible for the recipient relationship and message purpose.
01
Request a Sender ID
3 to 11 alphanumeric characters representing your brand, subject to approval.
02
Choose dashboard or API
Send manually from the workspace or integrate via REST API with Idempotency-Key.
03
Use expected content
Transactional messages only, without spam, promotions or misleading links.
04
Respect limits
Per-account and per-number quotas protect recipients and carrier routes.
06What happens after sending
Every accepted request leaves a trace.
The dashboard and API expose request_id, message_id and operational status. A delivery status confirms the carrier event; OTP codes are always masked as [OTP ocultado].
01 · ACCEPTED
Accepted & traced
Validation passed, credit reservation was linked to the provider ID and processing started.
02 · DLR & WEBHOOK
Signed status updates
History and HMAC-SHA256 webhooks reflect delivered or failed carrier events.
03 · SAFE BILLING
No premature debit
Requests rejected by validation or quota before provider dispatch never consume credits.
Next step
Test without risk, then move to production.
Use Sandbox OTP v2 to test expiry, attempts and single-use consumption at zero cost, or open the API documentation.
Before you integrate
Using SMS e OTP: what to know.
Check the requirements, usage rules and service boundaries before activating your integration. The documentation contains the full API contracts.
How should I handle request limits?
On HTTP 429, respect the Retry-After header when present. Avoid retry loops. Request limits, balance and OTP quotas are separate controls. A send timeout can have an unknown outcome: inspect the original operation before attempting a new send.
Does the status page guarantee delivery?
The page shows manually reported incidents. No incident report does not prove availability or delivery. For SMS, provider acceptance, DLR-reported delivery and code verification are distinct states; sandbox has no real delivery.
What do I need to get started?
Create an account, request a Sender ID representing your brand and wait for approval. Keep the API key on your server and use +244 followed by nine digits. Transactional use only.
How does usage work?
The current package includes 50 credits for 6,000 Kz. Each accepted SMS segment uses one credit; final text length and encoding may require multiple segments. A standard short OTP uses one credit per live send. Checking a code has no extra charge; another send uses balance again.
What are the limits and scope?
Simple OTP expires in five minutes, allows five attempts per request and three requests per hour per account and number, including requests cancelled after rejection. Verification requires authentication on your backend; include the returned otp_id. History hides the code. OTP requires an approved, active account sender; with Bearer and multiple senders, select one explicitly. API limits also apply. Scheduling and bulk sending require the first approved SMS top-up. For an account-bound second factor and a single-use proof, see Authenticator.
What should I check if something fails?
Check the request ID and status before resending. Acceptance does not prove delivery; delivered does not prove reading. After an uncertain result or timeout, check history before creating another send. Sandbox simulates responses and does not measure the real network.
Need help? Share the product, time, request ID and a description of the issue. Do not share API keys, OTP codes or personal message content. For account-specific capacity or commitments, confirm the conditions with support.