Skip to main content
Threetone’s website demo has a dedicated Twilio Verify flow. It sends a code and checks approval before proceeding with a demo-call request. This is not a public workspace verification API, an SMS conversation channel, or proof that calling is available for your deployment.

​
Prepare an application verification flow

For a separate application, identify the action being protected, the server responsible for verification, and the provider account owner. Use Twilio Verify’s Service, Verification, and Verification Check model. Do not copy demo-only routes into an application integration.
1

Bind the intended action

Associate the destination and verification attempt with the application request. A checked phone code should not grant access to unrelated workspaces or actions.
2

Bound code delivery

Validate the destination before sending. Define cooldowns and attempt limits on the server, and display retry timing in the interface. Keep provider credentials and verification requests server-side.
3

Check the result

Continue only after the provider approves the verification. Handle expired, incorrect, and exhausted codes explicitly. Do not treat a successful send response as a successful check.
4

Handle the protected action separately

A later call can fail even after verification succeeds. Keep code status, action authorization, and call status distinct so the user receives an accurate result.

​
Existing demo behavior

The demo checks phone and IP eligibility, applies send limits, and can return retry timing. Its call flow requires the code check to succeed and has separate configuration and execution requirements. Keep OTP values out of logs, screenshots, and support tickets. For a failed attempt, distinguish invalid destination, send cooldown, wrong or expired code, and downstream call failure. Do not resend automatically after every error.

​
Frequently asked questions

No. Workspace SMS routing remains disabled. Verification is a separate provider workflow.