The Sinch .NET SDK allows you to quickly interact with the suite of Sinch APIs from inside your .NET applications. When using the .NET SDK, the code representing requests and queries sent to and responses received from the suite of Sinch APIs are structured similarly to those that are sent and received using the suite of Sinch APIs.
The following links are available for your reference:
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 of the .NET SDK client class can be done in two ways, depending on which product you are using.
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"]));To start using the Voice API with the SDK, you need to initialize the main client class with your credentials from your Sinch dashboard and additionally create a Voice client object that uses your Voice app credentials.
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_access_key",
"YOUR_access_secret",
"YOUR_project_id");
var voice = sinch.Voice("YOUR_application_key", "YOUR_application_secret");Or, if you only need to use Voice API:
using Sinch;
var sinch = new SinchClient(default, default, default);
var voice = sinch.Voice("YOUR_application_key", "YOUR_application_secret");The Java SDK currently supports the following products:
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
}));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.AvailableNumbers.ActiveNumbers.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.
This guide describes the syntactical structure of the .NET SDK for the SMS API, including any differences that may exist between the API itself and the SDK. For a full reference on SMS API calls and responses, see the SMS REST API Reference.
The code sample below of how to use the .NET SDK to send an SMS message. We've also provided an example that accomplishes the same task using the REST API.
using System.Text.Json;
using Sinch;
using Sinch.SMS;
using Sinch.SMS.Batches.Send;
var sinch = new SinchClient("YOUR_project_id",
"YOUR_access_key",
"YOUR_access_secret",
// ensure you set the SMS hosting region.
options => options.SmsRegion = SmsRegion.Us);
var response = await sinch.Sms.Batches.Send(new SendTextBatchRequest
{
Body = "Hello! Thank you for using the Sinch .NET SDK to send an SMS.",
From = "YOUR_Sinch_phone_number",
To = new List<string>{"YOUR_recipient_phone_number"}
});
Console.WriteLine(JsonSerializer.Serialize(response, new JsonSerializerOptions()
{
WriteIndented = true
}));The Sinch .NET SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, Sinch.Sms.[Endpoint_Category].[Method()].
In the Sinch .NET SDK, SMS API endpoints are accessible through the client. The naming convention of the endpoint's representation in the SDK matches the API:
Sms.BatchesSms.DeliveryReportsSms.GroupsSms.Inbounds
For example:
var response = await sinch.Sms.Batches.Send(new SendTextBatchRequest
{
Body = "Hello! Thank you for using the Sinch .NET SDK to send an SMS.",
From = "YOUR_Sinch_phone_number",
To = new List<string>{"YOUR_recipient_phone_number"}
});The Sms.Batches category of the .NET SDK corresponds to the batches endpoint. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| Send | Send() |
| List batches | List() |
| Dry run | DryRun() |
| Get a batch message | Get() |
| Update a batch message | Update() |
| Replace a batch | Replace() |
| Cancel a batch message | Cancel() |
| Send delivery feedback for a message | SendDeliveryFeedback() |
The Sms.DeliveryReports category of the .NET SDK corresponds to the delivery_report and delivery_reports endpoints. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| Retrieve a delivery report | Get() |
| Retrieve a recipient delivery report | GetForNumber() |
| Retrieve a list of delivery reports | List() |
The Sms.Groups category of the .NET SDK corresponds to the groups endpoint. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| List groups | List() |
| Create a group | Create() |
| Retrieve a group | Get() |
| Update a group | Update() |
| Replace a group | Replace() |
| Delete a group | Delete() |
| List group member phone numbers | ListMembers() |
The Sms.Inbounds category of the .NET SDK corresponds to the inbounds endpoint. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| List incoming messages | List() |
| Retrieve inbound message | Get() |
Requests and queries made using the .NET SDK are similar to those made using the SMS API. Many of the fields are named and structured similarly. For example, consider the representations of an SMS API batch ID. One field is represented in JSON, and the other is using our .NET SDK:
BatchId = "{BATCH_ID}"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.
For example, consider this example in which the Get() method of the Sms.Batches class is invoked:
smsResponse = sinchClient.Sms.Batches.Get("BATCH_ID");
When using the SMS API, service_plan_id and batch_id would be included as path parameters in the JSON payload. With the .NET SDK, the batch_id parameter is included as an argument in the Get() method.
Note that the service_plan_id path parameter does not need to be included in any requests created by the .NET SDK.
When translating field names from the SMS 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 giving some examples of field names present in the SMS API and their modified counterparts in the SMS API .NET SDK:
| API field name | SDK field name |
|---|---|
type | Type |
from | From |
recipient_msisdn | recipientMsisdn |
Additionally, some fields which require string values in the SMS API have enum values in the .NET SDK. Consider the following example:
SmsType Type = SmsType.MtText;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.
This guide describes the syntactical structure of the .NET SDK for the Conversation API, including any differences that may exist between the API itself and the SDK. For a full reference on Conversation API calls and responses, see the Conversation REST API Reference.
The code sample below is an example of how to use the .NET SDK to send a text message on the SMS channel of a Conversation API app. We've also provided an example that accomplishes the same task using the REST API. (note that this REST API example uses Basic Authentication instead of OAuth2):
using System.Text.Json;
using Sinch;
using Sinch.Conversation;
using Sinch.Conversation.Messages.Send;
using Sinch.Conversation.Messages.Message;
using Sinch.Conversation.Common;
var sinch = new SinchClient("YOUR_project_id",
"YOUR_access_key",
"YOUR_access_secret",
// ensure you set the Conversation region.
options => options.ConversationRegion = ConversationRegion.Us);
var response = await sinch.Conversation.Messages.Send(new SendMessageRequest
{
Message = new AppMessage(new TextMessage("Hello! Thank you for using the Sinch .NET SDK to send an SMS.")),
AppId = "YOUR_app_id",
Recipient = new Identified
{
IdentifiedBy = new IdentifiedBy
{
ChannelIdentities = new List<ChannelIdentity>
{
new ChannelIdentity
{
AppId = "YOUR_app_id",
Identity = "RECIPIENT_number",
Channel = new ConversationChannel("SMS")
}
}
}
},
ChannelProperties = new Dictionary<string, string> { { "SMS_SENDER", "YOUR_sms_sender" } }
});
Console.WriteLine(JsonSerializer.Serialize(response, new JsonSerializerOptions()
{
WriteIndented = true
}));The Sinch .NET SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, Sinch.Conversation.[Endpoint_Category].[Method()].
In the Sinch .NET SDK, Conversation API endpoints are accessible through the client (either a general client or a Conversation-specific client). The naming convention of the endpoint's representation in the SDK matches the API:
MessagesAppsContactsEventsTranscodingCapabilityTemplatesV2WebhooksConversations
For example:
var response = await sinch.Conversation.Messages.Send(new SendMessageRequest
{
Message = new AppMessage(new TextMessage("Hello! Thank you for using the Sinch .NET SDK to send an SMS.")),
AppId = "YOUR_app_id",
Recipient = new Identified
{
IdentifiedBy = new IdentifiedBy
{
ChannelIdentities = new List<ChannelIdentity>
{
new ChannelIdentity
{
AppId = "YOUR_app_id",
Identity = "RECIPIENT_number",
Channel = new ConversationChannel("SMS")
}
}
}
},
ChannelProperties = new Dictionary<string, string> { { "SMS_SENDER", "YOUR_sms_sender" } }
});The Messages category of the .NET SDK corresponds to the messages endpoint. The mapping between the API operations and corresponding methods are described below:
| API operation | SDK method |
|---|---|
| Send a message | Send |
| Get a message | Get |
| Delete a message | Delete |
| List messages | List |
| Update a message's metadata | Update |
The Apps category of the .NET SDK corresponds to the apps endpoint. The mapping between the API operations and corresponding methods are described below:
| API operation | SDK method |
|---|---|
| List all apps for a given project | List |
| Create an app | Create |
| Get an app | Get |
| Delete an app | Delete |
| Update an app | Update |
The Contacts category of the .NET SDK corresponds to the contacts endpoint. The mapping between the API operations and corresponding methods are described below:
| API operation | SDK method |
|---|---|
| List contacts | List or ListAuto |
| Create a contact | Create |
| Get a contact | Get |
| Delete a contact | Delete |
| Update a contact | Update |
| Merge two contacts | Merge |
| Get channel profile | GetChannelProfile |
The Conversations category of the .NET SDK corresponds to the conversations endpoint. The mapping between the API operations and corresponding methods are described below:
| API operation | SDK method |
|---|---|
| List conversations | List or ListAuto |
| Create a conversation | Create |
| Get a conversation | Get |
| Delete a conversation | Delete |
| Update a conversation | Update |
| Stop conversation | Stop |
| Inject a message | InjectMessage |
| Inject an event | InjectEvent |
The Events category of the .NET SDK corresponds to the events endpoint. The mapping between the API operations and corresponding methods are described below:
| API operation | SDK method |
|---|---|
| Send an event | Send |
| Get an event | Get |
| Delete an event | Delete |
| List events | List or ListAuto |
The Transcoding category of the .NET SDK corresponds to the messages:transcode endpoint. The mapping between the API operations and corresponding methods are described below:
| API operation | SDK method |
|---|---|
| Transcode a message | Transcode |
The Capability category of the .NET SDK corresponds to the capability endpoint. The mapping between the API operations and corresponding methods are described below:
| API operation | SDK method |
|---|---|
| Capability lookup | Lookup |
The Webhooks category of the .NET SDK corresponds to the webhooks endpoint. The mapping between the API operations and corresponding methods are described below:
| API operation | SDK method |
|---|---|
| List webhooks | List |
| Create a new webhook | Create |
| Get a webhook | Get |
| Update an existing webhook | Update |
| Delete an existing webhook | Delete |
The TemplatesV2 category of the .NET SDK corresponds to the Templates-V2 endpoint. The mapping between the API operations and corresponding methods are described below:
| API operation | SDK method |
|---|---|
| List all templates belonging to a project ID | List |
| Creates a template | Create |
| Lists translations for a template | ListTranslations |
| Updates a template | Update |
| Get a template | Get |
| Delete a template | Delete |
Requests and queries made using the .NET SDK are similar to those made using the Conversation API. Many of the fields are named and structured similarly. When translating field names from the Conversation 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. For example:
AppId = "YOUR_app_id"Note that the fields have the same name. 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. For example, consider this example in which the get method of the message class is invoked:
var response = await sinch.Conversation.Messages.Get(
messageId = "YOUR_message_id",
messagesSource = "CONVERSATION_SOURCE"
)
When using the Conversation API, message_id would be included as a path parameter, and messages_source would be included as a query parameter in the JSON payload. With the .NET SDK, both parameters are included as arguments in the get method.
Response fields match the API responses. They are delivered as .NET objects.
When using the .NET SDK, the code representing requests and queries sent to and responses received from the Voice API are structured similarly to those that are sent and received using the Voice API itself.
This guide describes the syntactical structure of the .NET SDK for the Voice API, including any differences that may exist between the API itself and the SDK. For a full reference on Voice API calls and responses, see the Voice API Reference.
The code sample below is an example of how to use the .NET SDK to make a Text-to-speech phone call. We've also provided an example that accomplishes the same task using the REST API.
using System.Text.Json;
using Sinch;
using Sinch.Voice.Callouts.Callout;
var sinch = new SinchClient("YOUR_access_key",
"YOUR_access_secret",
"YOUR_project_id");
var voice = sinch.Voice("YOUR_application_key", "YOUR_application_secret");
CalloutResponse response = await voice.Callouts.Tts(new TextToSpeechCalloutRequest{
Destination = new Destination{
Type = DestinationType.Number,
Endpoint = "YOUR_phone_number"
},
Text = "This is a Text to speech callout to test the Sinch dotnet Voice SDK."
});
Console.WriteLine(JsonSerializer.Serialize(response, new JsonSerializerOptions()
{
WriteIndented = true
}));The Sinch .NET SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, Sinch.Voice.[Endpoint_Category].[Method()].
In the Sinch .NET SDK, Voice API endpoints are accessible through the client. The naming convention of the endpoint's representation in the SDK matches the API:
Voice.CalloutsVoice.CallsVoice.ConferencesVoice.Applications
For example:
using Sinch;
using Sinch.Voice.Callouts.Callout;
...
CalloutResponse response = await voice.Callouts.Tts(new TextToSpeechCalloutRequest{
Destination = new Destination{
Type = DestinationType.Number,
Endpoint = "YOUR_phone_number"
},
Text = "This is a Text to speech callout to test the Sinch dotnet Voice SDK."
});The Voice.Callouts category of the .NET SDK corresponds corresponds to the callouts endpoint. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| Makes a Text-to-speech callout | Tts() |
| Makes a Conference callout | Conference() |
| Makes a Custom callout | Custom() |
The Voice.Calls category of the .NET SDK corresponds corresponds to the calls endpoint. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| Update a call in progress | Update() |
| Get information about a call | Get() |
Manage a call with callLeg | ManageWithCallLeg() |
The Voice.Conferences category of the .NET SDK corresponds corresponds to the conferences endpoint. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| Get information about a conference | Get() |
| Manage a conference participant | ManageParticipant() |
| Remove a participant from a conference | KickParticipant() |
| Remove all participants from a conference | KickAll() |
The Voice.Applications category of the .NET SDK corresponds corresponds to the configuration endpoint. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| Return all the numbers assigned to an application | GetNumbers() |
| Assign a number or list of numbers to an application | AssignNumbers() |
| Unassign a number from an application | UnassignNumber() |
| Return the callback URLs for an application | GetCallbackUrls() |
| Update the callback URL for an application | UpdateCallbackUrls() |
| Returns information about a number | QueryNumber() |
Requests and queries made using the .NET SDK are similar to those made using the Voice 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 voice.calls.Get(CallId); var request = await client.GetAsync("https://calling.api.sinch.com/calling/v1/calls/id/" + CallId);Note that the path parameters that are used in the API are all passed as arguments to the corresponding .NET method.
When translating field names from the Voice 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.
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.
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.
This guide describes the syntactical structure of the .NET SDK for the Verification API, including any differences that may exist between the API itself and the SDK. For a full reference on Verification API calls and responses, see the Verification API Reference.
The code sample below is an example of how to use the .NET SDK to initiate an SMS Verification request. We've also provided an example that accomplishes the same task using the REST API.
//This example initiates a SMS PIN verification request using the .NET SDK.
using System.Text.Json;
using Sinch;
using Sinch.Verification.Start.Response;
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
}));The Sinch .NET SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, Sinch.Verification.[Endpoint_Category].[Method()].
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.VerificationVerification.VerificationStatus
For example:
using Sinch;
using Sinch.Verification.Start.Response;
StartSmsVerificationResponse response = await verification.Verification.StartSms("YOUR_phone_number");The Verification.Verification category of the .NET SDK corresponds corresponds to the verifications start endpoint. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| Start an SMS PIN verification request | StartSms() |
| Start a FlashCall verification request | StartFlashCall() |
| Start a Phone Call verification request | StartCallout() |
| Start a Data verification request | StartSeamless() |
| Report an SMS PIN verification code by the identity of the recipient | ReportSmsByIdentity() |
| Report a FlashCall verification by the identity of the recipient | ReportFlashCallByIdentity() |
| Report a Phone Call verification code by the identity of the recipient | ReportCalloutByIdentity() |
| Report an SMS PIN verification code by the ID of the verification request | ReportSmsById() |
| Report a FlashCall verification by the ID of the verification request | ReportFlashCallById() |
| Report a Phone Call verification code by the ID of the verification request | ReportCalloutById() |
The Verification.VerificationStatus category of the .NET SDK corresponds to the verifications endpoint. The mapping between the API operations and corresponding .NET methods are described below:
| API operation | SDK method |
|---|---|
| Get the status of a verification by the ID of the verification request | GetById() |
| Get the status of a verification by the identity of the recipient | GetByIdentity() |
| Get the status of a verification by a reference value | GetByReference() |
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.
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:
| API field name | SDK field name |
|---|---|
method | Method |
type | Type |
identity | Identity |
Additionally, there are certain fields that are represented by an .NET enum value instead of a string. For example:
| API field name | SDK field name |
|---|---|
method: "sms" | VerificationMethodEx.Sms |
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.