Add SMS and email one-time-code delivery to your application's sign-in and account verification flows with the Blocx Verify API.
Use the documented Verify service to deliver one-time codes over SMS and email, while your application stays in control of the account flow.
Give each verification step a clear purpose, a focused message, and a safe route back into your application.
People need to understand which account action caused the message and where they should enter the code.
Your product needs to distinguish requesting a code, delivering it, checking it, and deciding what access to grant.
Repeated requests and old messages should not make the account experience ambiguous or expose verification data in logs.
Follow each stage from the event in your system to the message your customer receives and the next action in your product.
Request a verification as part of signup and return the result to the same registration flow. Keep account creation and permission decisions in your backend.
Your registration code is 123456. Enter it in the application to continue.
Next step: Submit the code to your application's registration screen.
Tie the code request to the active sign-in attempt, rather than treating possession of an unrelated old message as authorization.
Your sign-in code is 123456. Enter it in the sign-in screen you opened. Do not share this code.
Next step: Complete the active sign-in verification step.
Use a verification step within your own policy for a sensitive settings change. Your application decides whether that step is sufficient for the risk.
Your account confirmation code is 123456. If you did not request this action, do not share the code and review account security.
Next step: Confirm the intended action inside the authenticated product.
Use your recovery policy to determine the allowed verification path. Do not turn a delivered code into a claim that identity or account ownership has been fully established.
Your account recovery code is 123456. Use it only in the recovery screen you opened. Do not share it.
Next step: Continue the recovery process under your account policy.
Use the documented Verify service for SMS or email. Associate the returned verification identifier with the current account action in your server-side state.
Show a clear purpose and recipient hint without revealing private account information. Submit the user's code through your backend, not with a browser-exposed API secret.
Follow the service's documented check, expiry, and error behavior. Your application decides what a successful check authorizes and how a failed attempt is handled.
Avoid logging secrets, submitted codes, and unnecessary recipient details in application logs or analytics.
SMS or email verification is not a claim of phishing-resistant authentication or a replacement for risk and authorization controls.
An AI caller can speak a verification code in a phone call through Blocx Voice. This is not a channel on the messaging Verify endpoint described here.
Voice and AI-caller services are separate offerings, not channels on the messaging Verify endpoint.
Blocx supplies the documented verification delivery and check interfaces. Your application owns users, sessions, recovery policy, risk decisions, and authorization.
Yes, the documented Verify service supports these flows. Follow the published service documentation for production configuration and channel requirements rather than inventing an endpoint or assuming every messaging channel has identical behavior.
Keep API credentials server-side. The frontend collects the user's code and talks to your own backend, which manages the verification identifier and calls the documented service.
Use the service's documented states, rate limits, and expiry behavior. Keep the verification associated with the active user action and present a clear resend or recovery path in your own application.
No. Codes shown on this page cannot verify an account. Exploring a workflow does not send messages or check codes.
On Scale and Volume, the documented Verify service can deliver codes through Telegram Gateway to a reachable Telegram account associated with the recipient's phone number. Telegram controls the message format; custom templates and senders are not supported. Your application handles unreachable recipients and decides what to do next. This does not promise automatic SMS fallback or a general-purpose Telegram chat interface.
Yes. The separate Blocx Voice service offers 2FA via an AI caller that phones the user and speaks the code. Contact Blocx for Voice setup and access; this is not a channel on the documented messaging Verify endpoint or JavaScript SDK.
Connect verification to one real account action, keep secrets on your server, and make the next step unmistakable in your own interface.
Talk to SalesBlocx is the programmable messaging product from OtterBlocx, LLC, headquartered in Cheyenne, Wyoming, United States.