api: 99.99%
// SECURITY

How we protect your verifications

The Tambua API ships verification codes — losing or leaking them is the worst possible failure. These are the controls we run to keep that from happening.

Encryption

All traffic to api.tambua.me is served over TLS 1.2+. Data at rest is encrypted using AES-256 on the underlying storage layer.

API authentication

Per-app API keys, scoped to test or live mode. Keys are stored hashed in our database; you only see the full key once at creation.

Verification tokens

Each /v1/otp/send response includes a signed verification token tied to the request. The token is verified on /v1/otp/verify so codes cannot be replayed against the wrong session.

Webhook signatures

Every webhook is signed with an HMAC in the X-Tambua-Signature header. The header includes a timestamp to prevent replay.

Per-app isolation

Apps are isolated at the database, secret and balance layer. A leaked test key cannot send live messages, and vice-versa.

Phone-number handling

Recipient numbers are hashed for log retention. Raw values are not stored beyond the delivery window. Logs show only the last 4 digits.

Compliance posture

Tambua is operated from Nairobi, Kenya and is building toward formal third-party attestations. While we are not yet certified under SOC 2 or ISO 27001, we align with these standards and GDPR compliance; that work is on the roadmap.

Responsible disclosure

Found a vulnerability? Please email security@tambua.me with reproduction steps. We respond within 48 hours and credit reporters publicly with their permission. Do not test against live customer apps without coordination.

Operational security

  • Production access is limited to engineers on call, gated by MFA.
  • All console actions on apps, tokens and webhooks are audit-logged per organisation.
  • Secrets (JWT signing keys, webhook secrets, carrier credentials) are encrypted with envelope encryption and rotated on a schedule.