Initiate a Flashcall verification request with Android Verification SDK
In this guide you will see:
- How to configure the verification SDK.
- Logic needed to initiate a single flashcall verification request.
- How SDK reports the verification to Sinch Platform.
Create global configuration
The global configuration object is used to provide properies that will be used by multiple verification attempts. You'll most like need to create only one such object and share it between multiple verification requests. Parameters that might be passed into it's builder are listed below:
| Parameter | Your value |
|---|---|
applicationContext | The application context bound to your Android application. (required) |
authorizationMethod | Authorization method that will be used to sign your requests when communicatin with Sinch Platform. (required) |
apiHost | The Sinch REST API endpoint (optional, defaults to https://verification.api.sinch.com/) |
interceptors | List of OkHttp interceptors that might be provided if you want to include some custom logic when sending HTTP requests to Sinch Plaform. Read more about OkHttp interceptors here. (optional) |
BasicAuthorizationMethod and AppKeyAuthorizationMethod. BasicAuthorizationMethod should only be used for testing purposes to bootstrap your application as soon as possible. For production ready codebase AppKeyAuthorizationMethod should be used in cooperation with callback sent to the backend. In order to use it modify the parameters listed below with values copied from your app's dashboard Apps section.| Parameter | Your value |
|---|---|
appKey | The application key bound to your application. (required) |
appSecret | The application secret bound to your application. It should be used only for testing purposes. Application secret should never be provided for SDK in production environment. |
Initiate Flashcall verification
Similarly to what we've done before when creating global configuration, this time we'll have to create verification specific configuration. Parameters that are accepted by the builder of flashcall method are listed below:
| Parameter | Your value |
|---|---|
globalConfig | The global configuration object created before. (required) |
number | Number in E.164 Format to be verified. (required) |
custom | The custom string field that can be used to pass verification specific data. Look here for more information. (optional) |
reference | String that used as a reference in the requests for tracking purposes. Look here for more information. (optional) |
honourEarlyReject | Flag indicating if the verification process should honour early rejection rules.. See Early reject reference for more information. (optional) |
During the verification process you'll be notified by the SDK about the verification process state by:
| Parameter | Your value |
|---|---|
initiationListener | This listener will be invoked with the result of the verification initiation request. If it's onInitiated callback is invoked you can assume that Sinch Verification Platform attempted to verify the given number by issuing a flashcall. Otherwise onInitializationFailed is invoked with an error parameter describing what went wrong (required) |
VerificationListener | The listener that is used to either notify the client about succesfull verification by invoking onVerified callback or a failure during the process by calling onVerificationFailed. (required) |
verification.initiate() to start the verification process!.Report flashcall verification result
After you've initialized your verification you'll see the following events happening:
- If the initiation process succeeded you should see
Verification Initiatedbeing logged in the Android Studio logcat output. - Few seconds after that you'll see an incoming phone call that will be automatically intercepted by the SDK and reported back to Sinch Platform.
- Finally, you should see an Android alert being presented on your application screen informing that the verification was succesfull.
In a real life use case, after that verified user of your application would be allowed to log into his account.
Note:
Due to the permissions being granted to the app initially, the SDK was able to intercept the call automatically and pass the verification code (which in case of flashcall verificaiton is the number that you're receiving the call from) back to the framework. If for some reason that fails, the verification code can be reported manually by calling
verification.verify method and passing the number you're receiving the call from as an argument.Additional resources
Learn more about the Verification API:
