TL;DR
Short answer: a polling-based SMS provider is enough for a basic Node.js OTP login, provided the auth service owns the polling schedule, retry limits, resend cooldown, and abuse prevention. I would use it for straightforward SMS verification, but I would choose a specialist authentication provider when voice, WhatsApp, RCS, or advanced omnichannel failover is a hard requirement.
No webhook is not the same as no delivery visibility. It means the application pulls status and verification results instead of letting provider callbacks drive its state machine. For my one-person SaaS, that is a reasonable trade when the login path stays small and predictable.
How should Node.js OTP login handle polling status, retry, and resend abuse?
The browser should never poll the SMS vendor directly. My Node.js auth service creates the challenge, stores a server-side challenge record, and returns an opaque challenge ID to the browser. A worker then polls the provider for delivery status, while the login endpoint checks the verification result through the server. The browser only sees product states such as “code sent,” “checking,” and “try again later.” It doesn't get a provider credential or a raw message identifier.
