The Sinch .NET SDK allows you to quickly interact with the Numbers API from inside your .NET applications. When using the .NET SDK, the code representing requests and queries sent to and responses received from the Numbers API are structured similarly to those that are sent and received using the Numbers API.
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.
This guide describes the syntactical structure of the .NET SDK for the Numbers API, including any differences that may exist between the API itself and the SDK. For a full reference on Numbers API calls and responses, see the Numbers API Reference.
The code sample below is an example of how to use the .NET SDK to list the available numbers given a set of constraints. We've also provided an example that accomplishes the same task using the REST API.
using System.Text.Json;
using Sinch;
using Sinch.Numbers;
using Sinch.Numbers.Available.List;
var sinch = new SinchClient("YOUR_project_id",
"YOUR_access_key",
"YOUR_access_secret");
var response = await sinch.Numbers.Available.List(new ListAvailableNumbersRequest
{
RegionCode = "US",
Type = Types.Local
});
Console.WriteLine(JsonSerializer.Serialize(response, new JsonSerializerOptions()
{
WriteIndented = true
}));
This example highlights the following required to successfully make a Numbers API call using the Sinch .NET SDK:
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.
To start using the SDK, you need to initialize the main client class with your credentials from your Sinch dashboard.
For testing purposes on your local environment it's fine to use hardcoded values, but before deploying to production we strongly recommend using environment variables to store the credentials.
using Sinch;
var sinch = new SinchClient("YOUR_project_id",
"YOUR_access_key",
"YOUR_access_secret");
You can also implement the client using ASP.NET dependency injection. SinchClient
is thread safe, so it's fine to add it as a singleton:
builder.Services.AddSingleton<ISinchClient>(x => new SinchClient(
builder.Configuration["YOUR_project_id"],
builder.Configuration["YOUR_access_key"],
builder.Configuration["YOUR_access_secret"]));
The Sinch .NET SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, Sinch.Numbers.[Endpoint_Category].[Method()]
.
In the Sinch .NET SDK, Numbers API endpoints are accessible through the client. The naming convention of the endpoint's representation in the SDK matches the API:
Numbers.Available
Numbers.Active
Numbers.Regions
For example:
using Sinch.Numbers.Available.List;
ListAvailableNumbersResponse numbers_available = await sinch.Numbers.Available.List(new ListAvailableNumbersRequest
{
RegionCode = "US",
Type = Types.Local
});
The Numbers.Available
category of the .NET SDK corresponds to the availableNumbers endpoint. The mapping between the API operations and corresponding .NET methods are described below:
API operation | SDK method |
---|---|
Rent the first available number matching the provided criteria | RentAny() |
Activate a new phone number | Activate() |
Search for available phone numbers | List() |
The Numbers.Active
category of the .NET SDK corresponds to the activeNumbers endpoint. The mapping between the API operations and corresponding .NET methods are described below:
API operation | SDK method |
---|---|
List active numbers for a project | List() |
Update active number | Update() |
Retrieve active number | Get() |
Release active number | Release() |
The Numbers.Regions
category of the .NET SDK corresponds to the availableRegions endpoint. The mapping between the API operations and corresponding .NET methods are described below:
API operation | SDK method |
---|---|
List available regions | List() |
Requests and queries made using the .NET SDK are similar to those made using the Numbers API. Many of the fields are named and structured similarly. For example, consider the representations of a Numbers API region code. One field is represented in JSON, and the other is using our .NET SDK:
RegionCode = "US"
Note that the fields are nearly the same. Additionally, path parameters, request body parameters, and query parameters that are used in the API are all passed as arguments to the corresponding .NET method.
When translating field names from the Numbers 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 Numbers API and their modified counterparts in the Numbers API .NET SDK:
API field name | SDK field name |
---|---|
regionCode | RegionCode |
type | Type |
numberPattern.pattern | NumberPattern |
phoneNumber | PhoneNumber |
smsConfiguration | SmsConfiguration |
capability | Capability |
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.