Testing

Introduction

We offer an easy way to test your integration of our API into your system. Free of charge.

To use our sandbox environment you have to use a test application. Go to the applications list in our portal and get the API key of a test application. If you do not have a test application yet, you can easily create one. Click on 'Add application', enter a name you want to call the application, select the 'Test application' checkbox and press the Create button. When the application is created, open it and there you see the API key of the test application and you can start sending test messages.

How it works: Each Twizo API call you do with the test API key is validated as normal, so when you send incorrect parameters the call will be rejected (see Errors for more details on the possible errors). When the call is valid, the Twizo API checks the last 5 digits of the phone number you set. Based on those last digits the testing environment will influence the behaviour of the message. How it behaves depends on the type of message you want to send and the last 5 digits you set.

Notes:

You will not be charged for these test calls and they will not be sent to the phone.

Regardless of the currency of your wallet, the sandbox will always return the currency code 'usd'.

If you are missing an option to cover a test case, please contact us and we will add that option.

Verification

With the testing environment you can fully test your verification flow. By filling in the phone number you can control the test verification. In the table below you can find an overview of the possible last 5 digits of the phone number. Anything not described in the table will have undefined behaviour but can be used in the future to cover other test scenarios.

In all these cases the verification is accepted by the API, so you will get a HTTP status code in the range of 2xx. After the call is accepted the verification will have the status as defined in the table.

When you request a test verification, a token will be generated as well. The generated token will have a defined value based on the token type (default value: numeric) and length (default value: 6) you set as you can see in this table:

Token length

Numeric

Alphanumeric

4

0123

A123

5

01234

A1234

6

012345

A12345

7

0123456

A123456

8

01234567

A1234567

9

012345678

A12345678

10

0123456789

A123456789

Example 1 - Test normal verification flow

To test the normal verification flow, submit a verification with a recipient number ending with '00xxx'. If you do not specify the tokenType and tokenLength, the token of this verification will be '012345'. So if you want to test the response when the token is valid enter the token 012345 or if you want to test the response for an invalid token enter any token other then '012345'. If you want to test the response for an expired token wait till the validity is expired, by default 60 seconds, and then verify the token or use a phone number ending with '03xxx'.

Example 3 - Test verify an expired verification

In this example we submit a verification where the verification will directly be set to expired. When you verify the token you will get the response that it is expired. Submit a verification with a recipient number ending with '03xxx'. When you verify the token you will get the HTTP status code '423 - Locked' with errorCode 102.

Verification widget

With the testing environment you can fully test your verification widget flow. By filling in the phone number you can control the test verification for sms and call. When you set a recipient ending with '00000', you can use the token '012345' as a valid token. When you set another recipient, the token will be a random number (and therefor hard to enter the correct token ;-)).

For testing backup codes in the widget, you first need to create backup codes using a test API key, see Testing backup codes for more details.

Backup codes

With the testing environment you can easily test your backup code flow. When you create backup codes for the identifier you have set, a predefined set of backup codes will be returned. These backup codes can be used to test, however in test modes they are only available for 7 days. After that the backup codes are removed.

SMS

With the testing environment you can fully test your SMS flow. By filling in the phone number you can control the test SMS, including delivery reports. In the table below you can find an overview of the possible last 5 digits of the phone number. Anything not described in the table will have undefined behaviour but can be used in the future to cover other test scenarios.

Number Lookup

With the testing environment you can fully test your Number Lookup flow. By filling in the phone number you can control the test Number Lookup, including delivery reports. In the table below you can find an overview of the possible last 5 digits of the phone number. Anything not described in the table will have undefined behaviour but can be used in the future to cover other test scenarios.

In all these cases the Number Lookup is accepted by the API, so you will get a HTTP status code in the range of 2xx. After the call is accepted the Number Lookup will have the status as defined in the table.

Example - Test Number Lookup with valid result

In this example we will submit a Number Lookup which will be performed successful and data is returned. Submit an SMS with a recipient number ending with '01xxx'.