Where SaaS uses OTP
A SaaS product has several independent verification journeys. Do not combine all of them under one code and state.
| Journey | OTP purpose | Example purpose |
|---|---|---|
| Signup | Verify a new user's phone | signup |
| Login | Confirm access before session creation | login |
| Recovery | Authorize account recovery | recovery |
| Invitation | Confirm the invitation recipient | invite |
| Phone change | Verify the new contact | change_phone |
| Admin action | Add a risk confirmation step | admin_action |
The purpose value binds a code to one action and must match across send and verify.
Verified signup
Do not activate a full account immediately after the signup button is pressed. Keep a limited pending state, send an OTP, and activate the user after successful verification.
The UI should show a masked phone, selected channel, five-minute expiration, and resend countdown. Error copy should not expose provider internals.
Passwordless login
One-time-code login reduces the need for a permanent password but still requires a secure server session. After success: true, create a fresh session, rotate its identifier, and apply normal device, role, and lifetime controls.
Return neutral send responses that do not reveal whether a phone number is registered.
Account recovery
Give recovery its own purpose. After verification, authorize only the limited recovery operation rather than arbitrary actions as the user.
For workspace owners and administrators, consider a recovery notification and an option to terminate other active sessions.
Sensitive actions
OTP can add confirmation when changing billing details, assigning an administrator role, creating an API key, exporting sensitive data, disabling protection, or transferring workspace ownership.
The decision must still consider session state, authorization, recent authentication, and transaction risk. OTP does not replace access control.
Cascade integration
The SaaS backend sends phone, channel, and purpose:
{
"phone": "77001234567",
"purpose": "login",
"channel": "telegram"
}
After user input, verify with the same phone and purpose. Store the Bearer token only in backend secrets.
See the integration guide and send reference for complete requests.
Pilot cost and metrics
WhatsApp and Telegram cost 3 credits per successful delivery. New accounts receive 1000 starting credits. SMS is represented technically, but the public provider is not live yet.
Pilot one or two critical journeys and measure signup completion, login success after send, send-to-verify time, resends per user, code and limit errors, credits per completed action, and support contacts.
SaaS checklist
- Signup, login, and recovery use different purpose values.
- The API key stays on the backend.
- A code expires after 5 minutes and cannot be reused.
- Send, verify, and resend are limited.
- Sessions start only after successful verification.
- Responses do not reveal account existence.
- Admin operations perform separate authorization and risk checks.
- Funnel metrics connect send to a completed product action.