Start enriching your app

Docs

REST

Introduction

This document serves as a user guide and documentation on how to use the Sinch Verification REST APIs. For general information on how to use the Sinch APIs including methods, types, errors and authorization, please check the Using REST page.

Overview

Use the Sinch Verification Service to verify end-user’s mobile phone numbers. The Sinch Verification APIs should be used in combination with the Verification SDKs for a complete end-to-end solution, though it is possible to only use the APIs. Currently, there are three verification methods supported:

  • FlashCall verification - Android only
  • PIN SMS verification - iOS, Android, Javascript
  • Callout verification (voice call) - iOS only

FlashCall verification

With the flashCall verification method, a user’s phone number is verified by triggering a “missed call” towards this number. The call is intercepted by the Android SDK in the mobile app and blocked automatically.

To initiate a flashCall verification, check the Android SDK documentation. For additional security, it is recommended that you control which verification requests should proceed and which ones not, by listening in your backend for the Verification Request Event and respond accordingly. Your backend will be notified on the result of the verification with the Verification Result Event.

PIN SMS verification

With the PIN SMS verification method, a user’s phone number is verified by sending an SMS containing a PIN code to this number. In the case of iOS or Javascript, the user needs to enter the PIN manually in the app, while for Android there is an option of intercepting the SMS message delivery and capturing the PIN code automatically.

To initiate a PIN SMS verification, check the iOS, Android and Javascript documentation. For additional security, it is recommended that you control which verification requests should proceed and which ones not, by listening in your backend for the Verification Request Event and respond accordingly. Your backend will be notified on the result of the verification with the Verification Result Event

Callout verification

With the callout verification method, a user’s phone number is verified by receiving a phone call and hearing a pre-recorded or text-to-speech message, advising the user to press a digit code. When the user presses the digit code in the dialpad, the verification is successful.

To initiate a callout verification, check the iOS documentation. For additional security, it is recommended that you control which verification requests should proceed and which ones not, by listening in your backend for the Verification Request Event and respond accordingly. Your backend will be notified on the result of the verification with the Verification Result Event

API Quick Reference

Verification API

    URI:  https://api.sinch.com/verification/v1


URLHTTP VerbFunctionalityNotes
/verificationsPOSTVerification RequestNot needed when using the Verification SDK
/verifications/{type}/{endpoint}PUTReport VerificationNot needed when using the Verification SDK
/verifications/id/{id}GETQuery Verification by id
/verifications/reference/{reference}GETQuery Verification by reference
/verifications/{type}/{endpoint}GETQuery Verification by Endpoint


Verification Callback API

EventHTTP VerbFunctionalityNotes
VerificationRequestEventPOSTVerification Request EventRecommended for security purposes
VerificationResultEventPOSTVerification Result EventRecommended for verification result tracking


How to use the Verification APIs

In combination with the Mobile or Web SDK (recommended)

The following diagram shows how to use the Verification APIs when using the iOS, Android or Javascript SDKs to initiate a verification.

Important: In this scenario, the Verification Request and Report Verification APIs do not need to be called explicitly by the app, since the SDK is handling that for you.

If you have configured a verification callback URL in the Sinch Portal (recommended), with every verification that is initiated by the app, Sinch will send a Verification Request Event to your backend, to get permission to perform the verification. If your backend allows the verification request to proceed, Sinch will trigger a flashcall, SMS or call towards the phone to be verified. Once the phone receives the flash-call, SMS or voice call, the SDK will report back the CLI or PIN respectively so that the Sinch platform can compare its validity. The Sinch backend responds with the result of the verification to the client and sends a Verification Result Event to your backend. The status of a verification can also be queried ad-hoc by using the “Query Verification” APIs.

Without the mobile or web SDK

If you are not using the mobile or web Verification SDKs, then you need to implement all the client logic for intercepting calls (in case of flashcalls) and reporting the CLI or PIN (in case of SMS or callout verification) inside your app. The following diagram shows how to use Sinch Verification in this scenario.

The verification requests will be triggered from your backend towards Sinch with the Verification Request API, by doing an application signed request. Sinch platform will respond with the CLI filter (for flashcalls) or the template (in case of an SMS), or the polling intervals (in case of a callout). As soon as the flashcall or SMS is received by your app, your backend will need to report back to Sinch the CLI or PIN that was reported through the Report Verification API. Sinch will respond with the result of the verification.

Verification API

URI:  https://api.sinch.com/verification/[version]

    Version - v1

The Sinch Verification API is used for verifying mobile phone numbers. It is consumed by the Sinch Verification SDK, but it can also be used by any backend or client directly.

[POST] /verifications
[PUT] /verifications/{type}/{endpoint}

The Sinch service uses three different verification methods:

  1. By sending an SMS message with a PIN code
  2. By placing a flashcall (missed call) and detecting the incoming calling number (CLI)
  3. By placing a PSTN call to the user’s phone and playing an announcement, asking the user to press a particular digit to verify the phone number (only iOS)

Verification Request

[POST] /verifications/ - Start a verification

This method is used by the mobile and web Verification SDKs to start a verification. It can also be used to request a verification from your backend, by making an Application signed request. It is a POST request which specifies the phone number that should be verified and the verification method.

Authorization

Authorization level can be specified in the Sinch dashboard, under your app settings. By default it is set to “Deny”. These schemes are allowed:

Request

[RequestBody]
    VerificationRequest

[VerificationRequest]
    identity - identity
    string - method
    string? - reference
    string? - custom 
    object? - metadata
    FlashCallOptions? - flashCallOptions
[FlashCallOptions]
    string? - cli
    int? - dialTimeout

identity indicates type of endpoint that will be verified and specifies the particular endpoint. The support endpoint type currently is only “number”.

method indicates the verification method. Possible values are:

  • flashCall
  • sms
  • callout

reference can be used to pass your own reference in the request for tracking purposes.

custom can be used to pass custom data in the request.

FlashCallOptions is an optional object for flashCall verifications. It allows you to specify Cli and dial time out parameters for flashCall. Cli is a particular number to be used as caller Id in the flashCall. The number that you specify needs to be a number that you have rented from the Sinch portal. DialTimeout should be specified in seconds and must be between 5 and 120. FlashCallOptions object can be specified optionally, and only if the verification request was triggered from your backend (no SDK client) through an application signed request.

By default you do not need to specify what CLI and dial time out to use. Sinch will pick a random CLI and optimize dial time out for your flashCall.

Example - FlashCall

[POST] https://api.sinch.com/verification/v1/verifications
{
    "identity": { "type":"number", "endpoint":"+46700000000" },
    "method": "flashCall"
} 

Example - FlashCall specifying CLI (no SDK scenario)

[POST] https://api.sinch.com/verification/v1/verifications

Request
{
    "identity": { "type":"number", "endpoint":"+46700000000" },
    "method": "flashCall",
    "flashCallOptions":{"cli":"+1234567890", "dialTimeout":10}
} 

Example - Sms

[POST] https://api.sinch.com/verification/v1/verifications
{
    "identity": { "type":"number", "endpoint":"+46700000000" },
    "method": "sms"
} 

Example - Callout

[POST] https://api.sinch.com/verification/v1/verifications
{
    "identity": { "type":"number", "endpoint":"+46700000000" },
    "method": "callout"
} 

Response

[RequestBody]
    VerificationResponse

[VerificationResponse]
    string - id
    SmsVerificationData? - sms
    FlashCallVerificationData? - flashCall
    CalloutVerificationData? - callout

[SmsVerificationData]
    string - template

[FlashCallVerificationData]
    string - cliFilter
    int - interceptionTimeout

[CalloutVerificationData]
    int - startPollingAfter
    int - stopPollingAfter
    int - pollingInterval

The response from the Sinch Verification service differs, depending on the verification method.

In case of a flashcall request, the response contains the following parameters:

cliFilter is the filter that should be applied for incoming calls to intercept the flashcall.

interceptionTimeout indicates the amount of seconds that the SDK client will be waiting for the flashcall.

Example - FlashCall

{
    "id":"1234567876",
    "flashCall":{"cliFilter":"(.*)70123(.*)","interceptionTimeout":120}
}

In case of an SMS verification, the response contains the template of the SMS to be expected and intercepted.

Example - Sms

{
    "id": "1234567890",
    "sms": { "template": "Your verfication code is {{CODE}}" }
}

In case of a callout verification (voice call), the response contains information for the client to poll for the verification result.

Example - Callout

{
    "id": "1234567890",
    "callout":{
        "startPollingAfter":3,
        "stopPollingAfter":30,
        "pollingInterval":3
        }
}

Report Verification

[PUT] /verifications/{type}/{endpoint} - Report back on a started verification

After the SMS or flashcall is received (and intercepted, in case of Android), the client needs to report to the Sinch Verification service either the PIN (for SMS) or CLI (for flashCall).

Authorization

Authorization level can be specified in the Sinch dashboard, under your app settings. By default it is set to “Deny”. If you are using this API to report a verification from your backend, you should use an Application signed request.

Request

[RequestBody]   
    VerficationReportRequest

[VerficationReportRequest]
    string - method
    SmsVerificationReportData? - sms
    FlashCallVerificationReportData? - flashCall

[SmsVerificationReportData]
    string - code
    string? - cli

[FlashCallVerificationReportData]
    string - cli

method indicates the verification method. Possible values are:

  • flashCall
  • sms

code indicates the PIN code that was inputted by the user in the app

cli indicates the caller Id of the flashCall or the sender Id of the SMS.

Example - FlashCall

[PUT] https://api.sinch.com/verification/v1/verifications/number/+46700000000
{
    "method": "flashCall",
    "flashCall": { "cli": "+46000000000" }
} 

Example - SMS

[PUT] https://api.sinch.com/verification/v1/verifications/number/+46700000000
{
    "method": "sms",
    "sms": { "code": "123" }
} 

The Sinch Verification backend will then validate the reported PIN or CLI and respond with success or failure.

Response

[ResponseBody]
    VerificationResult

[VerificationResult]
    string - id
    string - method
    string - status
    string? - reason
    string? - reference
    bool? - source

id is the verification id.

method shows the verification method. It can take the values:

  • “flashcall”
  • “sms”
  • “callout”

status shows the current status of the verification request. It can take the values:

  • “PENDING”: the verification is ongoing
  • “SUCCESSFUL”: the verification was successful
  • “FAIL”: the verification attempt was made, but the number was not verified
  • “DENIED”: the verification attempt was denied by Sinch or your backend
  • “ABORTED”: the verification attempt was aborted by requesting a new verification
  • “ERROR”: the verification could not be completed due to a network error or the number being unreachable.

reason shows the reason why a verification has FAILED, was DENIED or was ABORTED. It can take the values:

  • “Fraud”
  • “Not enough credit”
  • “Blocked”
  • “Denied by callback”
  • “Invalid callback”
  • “Internal error”
  • “Destination denied”
  • “Network error or number unreachable”
  • “Failed pending”
  • “SMS delivery failure”
  • “Invalid CLI”
  • “Invalid code”
  • “Expired”
  • “Hung up without entering valid code”

reference shows the reference Id that was passed (optionally) together with the verification request.

source This is free text that the client is sending, but it is used to show if the call/SMS was intercepted or not. Typical values can be:

  • “intercepted”
  • “manual”

Example - Response

{
    "id": "1234567890",
    "method": "sms",
    "status": "SUCCESSFUL",
    "source": "intercept"
} 

Query by ID

[GET] /verifications/id/{id} - Queries the verification result by sending the verification id

With this query you can get the result of a verification.

Authorization

This is a protected resource and requires an application signed request.

Request

[GET] /verifications/id/{id}

Response

[ResponseBody]
    VerificationResult

[VerificationResult]
    string - id
    string - method
    string - status
    string? - reason
    string? - reference
    string? - source

id is the verification id.

method shows the verification method. It can take the values:

  • “flashcall”
  • “sms”
  • “callout”

status shows the current status of the verification request. It can take the values:

  • “PENDING”: the verification is ongoing
  • “SUCCESSFUL”: the verification was successful
  • “FAIL”: the verification attempt was made, but the number was not verified
  • “DENIED”: the verification attempt was denied by Sinch or your backend
  • “ABORTED”: the verification attempt was aborted by requesting a new verification
  • “ERROR”: the verification could not be completed due to a network error or the number being unreachable.

reason shows the reason why a verification has FAILED, was DENIED or was ABORTED. It can take the values:

  • “Fraud”
  • “Not enough credit”
  • “Blocked”
  • “Denied by callback”
  • “Invalid callback”
  • “Internal error”
  • “Destination denied”
  • “Network error or number unreachable”
  • “Failed pending”
  • “SMS delivery failure”
  • “Invalid CLI”
  • “Invalid code”
  • “Expired”
  • “Hung up without entering valid code”

reference shows the reference Id that was passed (optionally) together with the verification request.

source This is free text that the client is sending, but it is used to show if the call/SMS was intercepted or not. Typical values can be:

  • “intercepted”
  • “manual”

Example - Query by Id

Request

[GET] https://api.sinch.com/verification/v1/verifications/id/1234567890

Response

{
    "id": "1234567890",
    "method": "sms",
    "status": "SUCCESSFUL",
    "source": "intercept"
} 

Query Verification by Reference

[GET] /verifications/reference/{reference} - Queries the verification result by sending the custom reference

With this query you can get the result of a verification by sending the reference.

Authorization

This is a protected resource and requires an application signed request.

Request

[GET] /verifications/reference/{reference}

Response

[ResponseBody]
    VerificationResult

[VerificationResult]
    string - id
    string - method
    string - status
    string? - reason
    string? - reference
    string? - source

id is the verification id.

method shows the verification method. It can take the values:

  • “flashcall”
  • “sms”
  • “callout”

status shows the current status of the verification request. It can take the values:

  • “PENDING”: the verification is ongoing
  • “SUCCESSFUL”: the verification was successful
  • “FAIL”: the verification attempt was made, but the number was not verified
  • “DENIED”: the verification attempt was denied by Sinch or your backend
  • “ABORTED”: the verification attempt was aborted by requesting a new verification
  • “ERROR”: the verification could not be completed due to a network error or the number being unreachable.

reason shows the reason why a verification has FAILED, was DENIED or was ABORTED. It can take the values:

  • “Fraud”
  • “Not enough credit”
  • “Blocked”
  • “Denied by callback”
  • “Invalid callback”
  • “Internal error”
  • “Destination denied”
  • “Network error or number unreachable”
  • “Failed pending”
  • “SMS delivery failure”
  • “Invalid CLI”
  • “Invalid code”
  • “Expired”
  • “Hung up without entering valid code”

reference shows the reference Id that was passed (optionally) together with the verification request.

source This is free text that the client is sending, but it is used to show if the call/SMS was intercepted or not. Typical values can be:

  • “intercepted”
  • “manual”

Example - Query by reference

Request

[GET] https://api.sinch.com/verification/v1/verifications/reference/abc_123

Response

{
    "id": "1234567123",
    "method": "sms",
    "status": "SUCCESSFUL",
    "source": "manual",
    "reference": "abc_123"
} 

Query by Endpoint

[GET] /verifications/{method}/{type}/{endpoint} - Queries the verification result by sending the number to be verified.

Authorization

The following endpoint is public authorized, so there is no need to use any signing for this request. This is so that the client can poll for the status of their callout verification without first being authorized.

Request

[GET] /verifications/{method}/{type}/{endpoint}

Response

[ResponseBody]
    VerificationResult

[VerificationResult]
    string - id
    string - method
    string - status
    string? - reason
    string? - reference
    string? - source

id is the verification id.

method shows the verification method. It can take the values:

  • “flashcall”
  • “sms”
  • “callout”

status shows the current status of the verification request. It can take the values:

  • “PENDING”: the verification is ongoing
  • “SUCCESSFUL”: the verification was successful
  • “FAIL”: the verification attempt was made, but the number was not verified
  • “DENIED”: the verification attempt was denied by Sinch or your backend
  • “ABORTED”: the verification attempt was aborted by requesting a new verification
  • “ERROR”: the verification could not be completed due to a network error or the number being unreachable.

reason shows the reason why a verification has FAILED, was DENIED or was ABORTED. It can take the values:

  • “Fraud”
  • “Not enough credit”
  • “Blocked”
  • “Denied by callback”
  • “Invalid callback”
  • “Internal error”
  • “Destination denied”
  • “Network error or number unreachable”
  • “Failed pending”
  • “SMS delivery failure”
  • “Invalid CLI”
  • “Invalid code”
  • “Expired”
  • “Hung up without entering valid code”

reference shows the reference Id that was passed (optionally) together with the verification request.

source This is free text that the client is sending, but it is used to show if the call/SMS was intercepted or not. Typical values can be:

  • “intercepted”
  • “manual”

Example - Query by endpoint

Request

[GET] https://api.sinch.com/verification/v1/verifications/callout/number/+46700000000

Response

{
    "id": "1234567890",
    "method": "callout",
    "status": "SUCCESSFUL",
    "reference": "abc_123"
} 

Important this endpoint can only be used for a limited time after the verification request.

Set SMS language

It is possible to specify the content language for SMS verification. The desired language is set in the initiate verification request ‘Accept-Language’ header. Setting this header is optional. If not included the application’s default SMS content language is used, which by default is en-US. If an SMS template for the desired language is not found it is defaulted to ‘en-US’ unless a different default language has been defined for the requesting application.

More information on the ‘Accept-Language’ header can be found from IETF and the HTTP/1.1 documentation.

Note: The content language specified in the API request or in the callback can be overridden by carrier provider specific templates, due to complience and legal requirements, such as US shortcode requirements (pdf).

Example - SMS verification specifying content language

Headers:
...
Accept-Language: es-ES
...

[POST] https://api.sinch.com/verification/v1/verifications
{
    "identity": { "type":"number", "endpoint":"+46700000001" },
    "method": "sms"
} 

The actual language that was selected is returned in the ‘Content-Language’ HTTP content header. As outlined above, this may differ from the requested language due to either that language not having SMS content defined, or it being overridden by provider requirements.

Example - SMS verification response with selected content language

Response

Headers:
...
Content-Length: 103
Content-Language: es-ES
Content-Type: application/json; charset=utf-8
Expires: -1
...

{
    "id":"1087388",
    "sms":
        {
            "template":"Tu código de verificación es {{CODE}}.",
            "interceptionTimeout":120
        }
}

Verification Callback API

Verification Request Event

This callback event is a POST request to the specified verification callback URL and is triggered when a new verification request is made from the SDK client or the Verification Request API. This callback event is only triggered when a verification callback URL is specified.

Authorization

You can find more information on callback request signing here.

Request

[RequestBody]
{
    string - id
    string - event
    string - method
    identity - identity
    money - price
    string? - reference
    string? - custom
    string[]? - acceptLanguage
}

Example

{
    "id":"1234567890",
    "event": "VerificationRequestEvent",
    "method": "sms",
    "identity": { "type":"number", "endpoint":"+46700000000" },
    "price": { "amount": 10.5, "currencyId":"USD" }     
}

Response

[ResponseBody]
    RequestEventResponse

[RequestEventResponse]
{
    string - action
    Sms? - sms
    FlashCall? - flashCall
    Callout? - callout
}

[Sms]
    string - code
    string[]? - acceptLanguage

[FlashCall]
    string? - cli
    int? - dialTimeout

[Callout]
    string? - locale 
    string? - ttsMenu
    string? - wavFile
    string? - pin

action allows or denies the verification to be executed. It can take these values:

  • allow
  • deny

Example - allow

{
    "action": "allow"
}

Example - deny

{
    "action": "deny"
}


SMS

code contains the SMS PIN that should be used. By default, the Sinch platform will automatically generate PIN codes for SMS verification. If you want to set your own PIN, you can specify it in the response to the Verification Request Event:

Example - SMS with pre-defined PIN

{
    "action": "allow",
    "sms": { "code": "12345" }
}

acceptLanguage allows to set (or override if provided in the API request) the SMS verification content language.

Please note that the content language specified in the API request or in the callback can be overridden by carrier provider specific templates, due to compliance and legal requirements, such as US shortcode requirements (pdf).

Example - Set the SMS language to Spanish (Spain)

{
    "action": "allow",
    "sms": 
        { 
            "code": "12345" ,
            "acceptLanguage": ["es-ES"]
        }
}


Flashcall

cli shows the phone number that will be displayed to the user when the flashcall is received on the user’s phone. By default, the Sinch platform will select randomly the CLI that will be displayed during a flashcall from a pool of numbers. If you want to set your own CLI, you can specify it in the response to the Verification Request Event:

Example - Flashcall with pre-defined CLI

{
    "action": "allow",
    "flashCall": { "cli": "+4445874587" }
}

Please note that in order to set your own CLI, you need to own the number that you will set.

dialTimeout shows the maximum time that a flashcall verification will be active and can be completed. If the phone number has not been verified successfully during this time, then the verification request will fail. By default, the Sinch platform will automatically optimize dial timeout during a flashcall. If you want to set your own dial time out for the flashcall, you can specify it in the response to the Verification Request Event:

Example - Flashcall with pre-defined dial timeout

{
    "action": "allow",
    "flashCall": { "dialTimeout": 10 }
}


Callout

locale it is used to indicate the language that should be used for the text-to-speech message. Only “en-US” is supported currently.

ttsMenu is the message that can be played to the user when the phone call is picked up. Default value is: “To verify your phone number, please press {pin}. If you didn’t request this call, please hangup.”

wavFile is the wav file that can be played to the user when the phone call is picked up.

pin is the digit that the user should press to verify the phone number. Default value is “1”.

Important: For the callout verification, if no ttsMenu nor wavFile is specified, then the user hears a text-to-speech message saying: “To verify your phone number, please press {pin}. If you didn’t request this call, please hangup.”

Please note that for the callout method you can either select to play a text-to-speech message, or a pre-recorded wav file. If you want to use the wav file, please contact Sinch support for instructions on how to supply the file to Sinch.

Example - callout

{
    "action": "allow",
    "callout": {
        "locale": "en-US",
         "ttsMenu": "Please press 1 to verify your phone",
         "pin": "1",
         "timeout": 60
    }

}

Verification Result Event

This callback event is is a POST request to the specified verification callback URL and triggered when a verification has been completed and the result is known. It is used to report the verification result to the developer’s backend application. This callback event is only triggered when the verification callback URL is specified.

Authorization

You can find more information on callback request signing here.

Request

[RequestBody]
    ResultEvent

[ResultEvent]
{
    string - id
    string - event
    string - method
    identity - identity
    string - status
    string? - reason
    string? - reference
    string? - source
    string? - custom
}

id is the verification id.

event contains the callback event that was received. It has the value “VerificationResultEvent”.

method shows the verification method. It can take the values:

  • “flashcall”
  • “sms”
  • “callout”

identity contains the endpoint information that is being verified. It contains a “type” object and an “endpoint” object

"identity": { "type":"number", "endpoint":"+46700000000" }

status shows the current status of the verification request. It can take the values:

  • “PENDING”: the verification is ongoing
  • “SUCCESSFUL”: the verification was successful
  • “FAIL”: the verification attempt was made, but the number was not verified
  • “DENIED”: the verification attempt was denied by Sinch or your backend
  • “ABORTED”: the verification attempt was aborted by requesting a new verification
  • “ERROR”: the verification could not be completed due to a network error or the number being unreachable.

reason shows the reason why a verification has FAILED, was DENIED or was ABORTED. It can take the values:

  • “Fraud”
  • “Not enough credit”
  • “Blocked”
  • “Denied by callback”
  • “Invalid callback”
  • “Internal error”
  • “Destination denied”
  • “Network error or number unreachable”
  • “Failed pending”
  • “SMS delivery failure”
  • “Invalid CLI”
  • “Invalid code”
  • “Expired”
  • “Hung up without entering valid code”

reference shows the reference Id that was passed (optionally) together with the verification request.

source This is free text that the client is sending, but it is used to show if the call/SMS was intercepted or not. Typical values can be:

  • “intercepted”
  • “manual”

custom displays a custom string that can be passed provided during a verification request.

Example

{
    "id":"1234567890",
    "event": "VerificationResultEvent",
    "method": "sms",
    "identity": { "type":"number", "endpoint":"+46700000000" },
    "status": "SUCCESSFUL"
}

Response

None

Call Detail Records

Call Detail Records (CDRs) can be downloaded from the Sinch portal. CDRs are in a semicolon-delimited file that contains the following fields

FieldTypeDescription
VerificationIdintA unique identifier for the verification request
UserSpaceIdintInternal identifier
MethodstringVerification method. Can be flashCall, sms or callout
StartTimestamptimeTime when the request was placed
EndTimestamptimeTime when the request was placed
ResultstringShows the result of the verification. It can be:

- "SUCCESSFUL": Number verified successfully
- "FAIL": Number was not verified
- "DENIED": Verification request was blocked (for reasons such as low credit,fraud etc)
- "ABORTED": Verification request was aborted, by initiating a new request
- "ERROR": There was an error processing the request, such as network congestions or number unreachable
ReasonstringReason for the result of a verification
CLIstringThe CLI that was used for a flashcall. Empty for SMS
IdentityTypestringThe identity type of the endpoint verified
IdentityEndpointnumberThe number verified
CountrystringThe country ID (ISO 3166-1 alpha-2) of the number verified
ReferencestringPartner reference id
CustomobjectFree field to be used as custom information
ApplicationKeystringApplication key
AmountdecimalDebited amount for the verification
CurrencystringCurrency

The files are generated once daily and contain the previous days’ CDRs. A day spans from 00:00:00 UTC to 23:59:59 UTC. CDRs are written when the call is ended, though there are some edge cases where an app-app call CDR may be delayed in being written, for example, if there is a network failure before the call is ended.

CDR files can be downloaded from the developer portal. Upon request, the CDR files can also be uploaded to a S3 bucket that your company provides and to which Sinch has write access.

Glossary

TermExplanation
RTCReal Time Communication
SDKSoftware Development Kit
PSTNPublic Switched Telephone Network (plain old telephony)
RESTRepresentational State Transfer
APIApplication Programming Interface
ACEAnswered Call Event
ICEIncoming Call Event
DiCEDisconnected Call Event
CDRCall Detail Record
IMInstant Messages
User SpaceUniverse of unique user names
Data CallPhone call over the Internet, also known as "VoIP"
VoIPVoice over IP
CODECCoder/Decoder
HTTPHyper Text Transfer Protocol
RTPReal time Protocol
UDPUser Datagram Protocol
IVRInteractive Voice Response
CDRCall Detail Record
SMSShort Message Service
NATNetwork Address Translation
MXPMedia eXchange Protocol
SVAMLSinch Voice Application Markup Language