How It Works
Zeckta uses a Session-Based approach. Every OTP request generates a uniquesessionId which must be provided during the verification phase. This ensures that the code entered by the user is validated against the specific attempt triggered by your application.
The Lifecycle Flow
- Request: Your application triggers an OTP for a destination phone number.
- Storage: Zeckta generates a 6-digit code, hashes it using SHA-256 with a secure pepper, and stores the session in a Redis cache.
- Delivery: The message is queued and dispatched via the high-speed SMS outbox.
- Verification: The user submits the code; Zeckta compares hashes and returns the validation result.
Default Configuration
To maintain high security and protect your workspace from brute-force attempts, the following defaults are enforced:| Setting | Default Value | Description |
|---|---|---|
| Code Length | 6 Digits | Numeric characters (0-9). |
| Expiry (TTL) | 3 Minutes | Sessions are automatically purged after 180 seconds. |
| Max Attempts | 3 Attempts | The session is locked/deleted after 3 failed tries. |
| Rate Limit | 3 per 10 min | Limits requests per phone number to prevent spam. |
| Session Reuse | Enabled | Reuses an active session if a new request is made within the TTL. |
API Endpoints
| Action | Method | Endpoint |
|---|---|---|
| Send OTP | POST | /v1/messaging/otp/request |
| Verify Code | POST | /v1/messaging/otp/verify |
Security Features
- Salted Hashing: Codes are never stored in plain text. We use SHA-256 hashing combined with a system-level pepper and the unique
sessionIdas a salt. - Anti-Abuse: Integrated rate-limiting at the workspace and destination levels ensures your SMS credits are protected from automated scripts.
- Audit Trail: Every request and verification attempt is logged in a persistent audit database for security compliance and troubleshooting.