Understand OTP and alternate sign-in options
Driver App can present different sign-in controls according to project configuration. Use only a method currently visible for your Driver account. A configured setting, visible tab, generated-code message, provider screen, or closed modal does not prove that the method is available end to end, that a code was delivered, or that a Driver session was accepted.
:::warning Requesting a code is an external effect
Get verify code and Resend code can create a code record and start email, SMS, plugin, or other configured provider work. Select either control only for your own Driver account and only when you intend to continue. Do not request codes repeatedly to test delivery.
:::
Availability
The exact controls depend on returned configuration and provider setup:
| Option or control | What may be visible | Important boundary |
|---|---|---|
| Password | Email or cellphone plus Password and Login | Follow Sign in as a driver; password behavior does not establish alternate-method behavior |
| Email OTP | OTP Email, Email, and Get verify code | Visibility does not prove code generation, delivery, validity, or Driver-role acceptance |
| Cellphone OTP | Country code, cellphone, and Get verify code in a configuration-selected OTP state | The current UI does not establish one universal cellphone-OTP entry across configurations |
| Phone-provider verification | A separate Get Verify Code control and verification modal can appear with cellphone password sign-in | This is a different request and session branch from generic OTP |
| reCAPTCHA | Verify reCAPTCHA or an embedded challenge | It is a conditional challenge, not a sign-in method or provider-success receipt |
Current source also contains device-code and provider-specific handlers without a productive visible control in the accepted Driver App Login page. A WhatsApp OTP setting has no dedicated visible WhatsApp control there. Do not infer that an unseen handler or enabled-looking setting is reachable.
State and result matrix
| State | Safe interpretation |
|---|---|
| Option absent | The current UI did not expose that method; no conclusion about account or provider existence follows |
| Identifier field visible | Driver App selected a configured form state |
| Get verify code visible | A request control is available; no code exists yet |
| Request loading | Local/provider request handling is unresolved |
| Code-sent message | One layer reported generation/send intent; delivery is not proved |
| Code-entry modal | Driver App is ready to collect a one-time code |
| Countdown running | The local modal timer is active; server/provider validity remains separate |
| Resend code disabled | Local resend delay has not elapsed |
| Validation or wait message | Local, rate-limit, provider, or server validation blocked the current step |
| reCAPTCHA checked-looking | The local challenge UI received a result; authentication is not proved |
| Modal closes or Login disappears | Local navigation/session state changed; role, persistence, provider, and post-login gates remain separate |
OTP stages are separate
Treat an OTP attempt as distinct stages:
- The configured option is visible.
- The identifier passes local validation.
- Driver App requests code generation.
- A provider accepts delivery work.
- The code reaches the intended person.
- Driver App submits the entered code.
- The backend accepts the code and returns an account/session result.
- Driver App applies the relevant local account/role handling.
- The signed-in navigation and later permission/schedule gates settle.
No stage proves the next. In particular, a generic OTP branch and a separate phone-provider verification branch do not have one proven, equivalent role-gate contract. Use only an operator-provisioned Driver account; Driver App source does not establish that every alternate branch repeats the standard password role check uniformly.
reCAPTCHA and provider boundaries
reCAPTCHA can depend on project settings, version, site key, base URL, platform configuration, and provider response. Missing setup can leave the challenge unavailable or produce an error. A challenge can also be reset or replaced by another version after a verification error.
Email, SMS, WhatsApp, phone verification, and plugin channels have separate configuration, rate limits, delivery systems, retry timing, and failure modes. Driver App cannot confirm provider delivery from a local code-sent message.
Troubleshooting
The expected OTP option is missing
Use only a method currently displayed. If your operator expects another method, ask them to review the Driver App project configuration and released build. Do not try to reveal an unregistered handler.
Get verify code shows an error or wait message
Check the email address or cellphone and country code once. Follow the displayed wait period before another request. Repeated requests can extend limits or send multiple provider messages.
The code does not arrive
Do not keep selecting Resend code. Confirm the destination without sharing the code, wait for the current provider attempt, then contact the project operator. A sent-looking message is not delivery evidence.
Driver App asks for reCAPTCHA but it does not load
Do not bypass the challenge or repeat Login. The current project can have missing or incompatible provider configuration. Contact the operator that maintains the released Driver App.
The code is rejected or time expires
Use only the most recent code sent to you and follow the visible resend timing. Do not share a code or enter codes from another project/account. If the state does not recover, return to Login and use an available operator-approved method.
An alternate method appears to sign in but access is unexpected
Leave the app without performing Driver actions and contact the project operator. Alternate branches do not have one proven equivalent Driver-role gate, and navigation alone is not authorization proof.
Related guides: Sign in as a driver · Understand startup and loading · Driver App overview