Sinch .NET SDK for Verification

The Sinch Verification .NET SDK allows you to quickly interact with the Verification API from inside your .NET applications. The fastest way to get started with the SDK is to check out our getting started guides. There you'll find all the instructions necessary to download, install, set up, and start using the SDK.

Syntax

When using the .NET SDK, the code representing requests and queries sent to and responses received from the Verification API are structured similarly to those that are sent and received using the Verification API itself.

The code sample on the side of this page is an example of how to use the .NET SDK to initiate an SMS Verification request. The code is also displayed below, along with a Verification REST API call that accomplishes the same task, for reference:

using System.Text;
using System.Text.Json;

class Program
{
    private const string _to = "<REPLACE_WITH_TO_NUMBER>";
    private const string _key = "<REPLACE_WITH_APP_KEY>";
    private const string _secret = "<REPLACE_WITH_APP_SECRET>";

    private const string _sinchUrl = "https://verification.api.sinch.com/verification/v1/verifications";
    static async Task Main(string[] args)
    {
        await SendSMSPinWithBasicAuth();
    }

    private static async Task SendSMSPinWithBasicAuth()
    {
        using (var _client = new HttpClient())
        {
            var requestBody = GetSMSVerificationRequestBody();
            var base64String = Convert.ToBase64String(Encoding.UTF8.GetBytes($"{_key}:{_secret}"));

            var requestMessage = new HttpRequestMessage(HttpMethod.Post, _sinchUrl);
            requestMessage.Headers.TryAddWithoutValidation("authorization", "basic " + base64String);
            requestMessage.Content = requestBody;

            var request = await _client.SendAsync(requestMessage);

            Console.WriteLine(request.StatusCode + " " + request.ReasonPhrase);
            Console.WriteLine(await request.Content.ReadAsStringAsync());

            request.EnsureSuccessStatusCode();
        }
    }
    public static StringContent GetSMSVerificationRequestBody()
    {
        var myData = new
        {
            identity = new {
                type = "number",
                endpoint = _to
            },
            method = "sms",
        };

        return new StringContent(
            JsonSerializer.Serialize(myData),
            Encoding.UTF8,
            Application.Json
        );
    }
}

using System.Text.Json;
using Sinch;
using Sinch.Verification.Report.Request;

var sinch = new SinchClient("YOUR_access_key", 
                            "YOUR_access_secret", 
                            "YOUR_project_id");

var verification = sinch.Verification("YOUR_application_key", "YOUR_application_secret");

var response = await verification.Verification.StartSms("YOUR_phone_number");
    
Console.WriteLine(JsonSerializer.Serialize(response, new JsonSerializerOptions()
{
    WriteIndented = true
}));

This example highlights the following required to successfully make a Verification API call using the Sinch .NET SDK:

• Client initialization
• Verification domain access
• Endpoint usage
• Field population

Client

When using the Sinch .NET SDK, you initialize communication with the Sinch backend by initializing the .NET SDK's main client class. This client allows you to access the functionality of the Sinch .NET SDK.

Initialization

To start using the Verification API with the SDK, you need to initialize the main client class with your credentials from your Sinch dashboard and additionally create a Verification client object that uses your Verification app credentials.

using Sinch;

var sinch = new SinchClient("YOUR_project_id",
                            "YOUR_access_key", 
                            "YOUR_access_secret");

var verification = sinch.Verification("YOUR_application_key", "YOUR_application_secret");

Or, if you only need to use Verification API:

using Sinch;

var sinch = new SinchClient(default, default, default);

var verification = sinch.Verification("YOUR_application_key", "YOUR_application_secret");

Verification domain

Endpoint categories

In the Sinch .NET SDK, Verification API endpoints are accessible through the client. The naming convention of the endpoint's representation in the SDK matches the API:

• Verification.Verification
• Verification.VerificationStatus

For example:

    using Sinch;
    using Sinch.Verification.Start.Response;

    StartSmsVerificationResponse response = await verification.Verification.StartSms("YOUR_phone_number");

Verification.Verification endpoint category

Verification.VerificationStatus endpoint category

Request and query parameters

Requests and queries made using the .NET SDK are similar to those made using the Verification API. Many of the fields are named and structured similarly. For example, consider a request to check on the status of a verification request by using the Identity of the request. One request is using the REST API, and the other is using our .NET SDK:

    var response = await verification.VerificationStatus.GetByIdentity("YOUR_phone_number", VerificationMethod.Sms);

    var request = client.GetAsync("https://verification.api.sinch.com/verification/v1/verifications/" + "YOUR_verification_method" + "/number/" + "YOUR_phone_number").Result;

Note that the path parameters that are used in the API are all passed as arguments to the corresponding .NET method.

Field name differences

When translating field names from the Verification API to the .NET SDK, remember that many of the API field names are in camelCase. In the .NET SDK, field names are in PascalCase. This pattern change manages almost all field name translations between the API and the SDK.

Below is a table detailing field names present in the Verification API and their modified counterparts in the Verification API .NET SDK:

Additionally, there are certain fields that are represented by an .NET enum value instead of a string. For example:

Responses

Response fields match the API responses. They are delivered as .NET objects. If there are any responses that differ significantly from the API responses, we note them in the endpoint category documentation.