post

/verify/smart

When you send a POST request with the end user’s phone number to the API’s subresource, the Smart Verify web service sends the verification code using the method determined best (as above) for the phone number in the request. This is typically the phone number that the end user submitted, although this can vary as TeleSign sometimes needs to modify the number in order to route it correctly. NOTE: If you try this API out using the API Explorer, you will be billed for the transaction as you normally would.

All requests submitted for the Smart Verify API:

  • Can be authenticated with Basic (easiest to implement) and Digest
  • Use https://rest-ww.telesign.com/v1/verify/smart as the base endpoint
  • Accept only UTF-8 encoded unicode characters as inputs
  • Use Content-Type application/x-www-form-urlencoded in request headers

Authorization

basic

Request Body

Schema
object
phone_number
string

The end user’s phone number you want to send a message to, including the country code, as a string of digits without spaces or special characters, beginning with the country dialing code.

required
ucid
string

A string specifying a use case code. Choices include -

  • ATCK - for use in a 2FA situation like updating an account or logging in
  • BACF - for creating an account where the service may be vulnerable to bulk attacks and fraudsters
  • BACS - for creating an account where the service may be vulnerable to bulk attacks or individual spammers
  • CHBK - for use when someone is trying to buy something expensive or unusual and you want to verify it is really them
  • CLDR - calendar event
  • LEAD - for use in a situation where you require a person to enter personal information in order to obtain information about something like a loan or realty or school, and you want to check if the person is bogus or not
  • OTHR - if you have a situation not addressed by other tags
  • PWRT - for use in a situation where a password reset is required
  • RESV - for use when you have end users making reservations and not showing up, and you want to be able to include phone verification in the loop
  • RXPF - for use when you are trying to prevent prescription fraud
  • SHIP - for use when you are sending a shipping notification
  • THEF - for use when you are trying to prevent an end user from deactivating or redirecting a phone number in order to take over someone else’s identity
  • TRVF - for use when you are transferring money and you want to check to see if it is approved by sending a text message or phone call to your end user. This is similar to CHBK, but is specifically for a money transaction
  • UNKN - if you have a situation not addressed by other tags (same as OTHR)
tts_message
string

If you choose to pass a custom message, you use this parameter to indicate what the custom message would be for text to speech (TTS). You MUST set the language parameter if you use this parameter. If a language is not supported, TeleSign may choose a default for you. If you do not set the language tag, United States English is assumed. Make sure to use $$CODE$$ in your message string, as this will generate and insert a random string with appropriate length as part of your TTS message.

language
string

If you use the tts_message parameter you must set the language. Choose from the list of supported languages

sms_message
string

If you choose to pass a custom message, you use this parameter to indicate what the custom message would be if an SMS is sent.

preference
string

Allows you to override the Smart Verify method selection. You can specify Voice Verify (use call) or SMS Verify (use sms) to be the recommended method to attempt. TeleSign uses the override method whenever possible. Since not all methods are supported on all devices, TeleSign may ignore the selected override method, in order to provide the method that is most appropriate, in which case Telesign selects the method in the order of sms and call. (Voice Verify maps to call.)

ignore_risk
boolean

Allows you to override the Smart Verify method selection. You can specify Voice Verify (use call) or SMS Verify (use sms) to be the recommended method to attempt. TeleSign uses the override method whenever possible. Since not all methods are supported on all devices, TeleSign may ignore the selected override method, in order to provide the method that is most appropriate, in which case Telesign selects the method in the order of sms and call. (Voice Verify maps to call.)

Responses

Your request was fulfilled and resulted in a new resource being created. If you want to code against a response, you should retrieve the status or error code and use that rather than the HTTP status response. Responses are based on the subresource used. If you got back ‘call’ for the subresource parameter, review responses for Voice Verify. If you got back ‘sms’ for the subresource parameter, review responses for SMS Verify.

Send a Test Request

Send requests directly from the browser (CORS must be enabled)
$$.env
2 variables not set
username
password