Python SDK

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude

The Sinch Python SDK allows you to quickly interact with the suite of Sinch APIs from inside your Python applications. When using the Python 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.

Client

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

Initialization

Initialization of the Python SDK client class can be done in two ways, depending on which product you are using.

Unified Project Authentication

To start using the SDK, you need to initialize the main client class with your credentials from your Sinch dashboard.

from sinch import SinchClient

sinch_client = SinchClient(key_id="key_id", key_secret="key_secret", project_id="YOUR_project_id")

import os
from sinch import SinchClient

sinch_client = SinchClient(
    key_id=os.getenv("KEY_ID"),
    key_secret=os.getenv("KEY_SECRET"),
    project_id=os.getenv("PROJECT_ID")
)

Application Authentication

from sinch import SinchClient

sinch_client = SinchClient(
    application_key="YOUR_application_key",
    application_secret="YOUR_application_secret"
)

import os
from sinch import SinchClient

sinch_client = SinchClient(
    application_key=os.getenv("APPLICATION_KEY"),
    application_secret=os.getenv("APPLICATION_SECRET")
)

Domains

The Python SDK currently supports the following products:

Numbers

SMS

Conversation

Voice

Verification

Numbers Domain

The code sample on this page is an example of how to use the Python 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.

from sinch import SinchClient

sinch_client = SinchClient(
    key_id="YOUR_key_id",
    key_secret="YOUR_key_secret",
    project_id="YOUR_project_id"
)

available_numbers_response = sinch_client.numbers.available.list(
    region_code="YOUR_region_code",
    number_type="YOUR_number_type"
)

print(available_numbers_response)

The Sinch Python SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, sinch_client.numbers.[endpoint_category].[method]. You can also create a domain-specific client from a general client. For example:

from sinch import SinchClient

sinch_client = SinchClient(key_id="YOUR_key_id", key_secret="YOUR_key_secret",
project_id="YOUR_project_id")

from sinch.domains.numbers import Numbers

numbers_client = Numbers(sinch_client)

Endpoint categories

In the Sinch Python SDK, Numbers API endpoints are accessible through the client (either a general client or a Numbers-specific client). The naming convention of the endpoint's representation in the SDK matches the API:

• available
• active
• regions

For example:

numbers_available = sinch_client.numbers.available.list(
    region_code="US",
    number_type="LOCAL"
)

available endpoint category

The available category of the Python SDK corresponds to the availableNumbers endpoint. The mapping between the API operations and corresponding Python methods are described below:

active endpoint category

The active category of the Python SDK corresponds to the activeNumbers endpoint. The mapping between the API operations and corresponding Python methods are described below:

regions endpoint category

The regions category of the Python SDK corresponds to the availableRegions endpoint. The mapping between the API operations and corresponding Python methods are described below:

Request and query parameters

Requests and queries made using the Python 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 Python SDK:

region_code = "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 Python method.

Field name differences

When translating field names from the Numbers API to the Python SDK, remember that many of the API field names are in camelCase, whereas the Python SDK field names are in snake_case. 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 Python SDK:

Nested objects

When making calls directly to the API, we use JSON objects, including (in some cases) nested JSON objects. When using the Python SDK, we use dictionaries instead of nested JSON objects. For example, consider the sms configuration objects below. One is represented in JSON, the other as a Python dictionary:

sms_configuration = {
    "servicePlanId": "service_plan_string"
}

Note that, in both cases, the servicePlanId object is structured in exactly the same way as they would be in a normal Python call to the Numbers API. When using the Python SDK, any argument that represents a nested JSON object will be represented as a Python dictionary at the top level, but the contents of that dictionary must be represented as JSON objects.

Responses

Response fields match the API responses. They are delivered as Python objects, with each top-level field represented as a property. Note that any nested objects normally returned by the Numbers API are returned as dictionaries by the Python SDK. Additionally, if there are any responses that differ significantly from the API responses, we note them in the endpoint category documentation.

SMS Domain

The code sample below is an example of how to use the Python SDK to send a text message using the SMS API. We've also provided an example that accomplishes the same task using the REST API.

from sinch import SinchClient

sinch_client = SinchClient(
    key_id="YOUR_key_id",
    key_secret="YOUR_key_secret",
    project_id="YOUR_project_id"
)

send_batch_response = sinch_client.sms.batches.send(
    body="Hello from Sinch!",
    to=["YOUR_to_number"],
    from_="YOUR_Sinch_number",
    delivery_report="none"
)

print(send_batch_response)

The Sinch Python SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, sinch_client.sms.[endpoint_category].[method]. You can also create a domain-specific client from a general client. For example:

from sinch import SinchClient

sinch_client = SinchClient(key_id="YOUR_key_id", key_secret="YOUR_key_secret",
project_id="YOUR_project_id")

from sinch.domains.sms import SMS

SMS_client = SMS(sinch_client)

Endpoint categories

In the Sinch Python SDK, SMS API endpoints are accessible through the client (either a general client or a SMS-specific client). The naming convention of the endpoint's representation in the SDK matches the API:

• groups
• batches
• inbounds
• delivery_reports

For example:

send_batch_response = sinch_client.sms.batches.send(
    body = "Hello from Sinch!",
    to = ["YOUR_to_number"],
    from_ = "YOUR_Sinch_number",
    delivery_report = "none"
)

batches endpoint category

The batches category of the Python SDK corresponds to the batches endpoint. The mapping between the API operations and corresponding Python methods are described below:

inbounds endpoint category

The inbounds category of the Python SDK corresponds to the inbounds endpoint. The mapping between the API operations and corresponding Python methods are described below:

groups endpoint category

The groups category of the Python SDK corresponds to the groups endpoint. The mapping between the API operations and corresponding Python methods are described below:

delivery_reports endpoint category

The delivery_reports category of the Python SDK corresponds to the delivery_report and delivery_reports endpoints. The mapping between the API operations and corresponding Python methods are described below:

Request and query parameters

Requests and queries made using the Python SDK are similar to those made using the SMS API. Many of the fields are named and structured similarly. In most cases, they are the same. For example, consider the representations of a SMS API app ID below. One field is represented in JSON, and the other is using our Python SDK:

batch_id = "{BATCH_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 python method. For example, consider this example in which the get method of the batch class is invoked:

SMS_response = sinch_client.sms.batches.get("01GR4H81QVX78E06F8ETGQ1CZK")

When using the SMS API, service_plan_id and batch_id would be included as path parameters in the JSON payload. With the Python SDK, the batch_id parameter is included as an argument in the get method.

Field name differences

Below is a table detailing field names present in the SMS API and their modified counterparts in the SMS API Python SDK:

Nested objects

When making calls directly to the API, we use JSON objects, including (in some cases) nested JSON objects. When using the Python SDK, we use dictionaries instead of nested JSON objects.

Responses

Response fields match the API responses. They are delivered as Python objects, with each top-level field represented as a property. Note that any nested objects normally returned by the SMS API are returned as dictionaries by the Python SDK.

Conversation Domain

The code sample below is an example of how to use the Python SDK to send a text message on the SMS channel of a Conversation API app. The Conversation API call that accomplishes the same task is displayed below for reference.

from sinch import SinchClient

sinch_client = SinchClient(
    key_id="YOUR_key_id",
    key_secret="YOUR_key_secret",
    project_id="YOUR_project_id"
)

# conversation_region must be set to either us or eu
sinch_client.configuration.conversation_region="us"

send_conversation_api_message_response = sinch_client.conversation.message.send(
    app_id="YOUR_app_id",
    recipient={
        "identified_by" : {
            "channel_identities" : [
                {"identity":"RECIPIENT_number","channel" : "SMS"}
            ]
        }
    },
    message={
        "text_message" : {
            "text" : "Text message from Sinch Conversation API."
        }
    },
    channel_properties={
        "SMS_SENDER" : "YOUR_sms_sender"
    }
)

print(send_conversation_api_message_response)

The Sinch Python SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, sinch_client.conversation.[endpoint_category].[method]. You can also create a domain-specific client from a general client. For example:

from sinch import SinchClient

sinch_client = SinchClient(key_id="YOUR_key_id", key_secret="YOUR_key_secret",
project_id="YOUR_project_id")

from sinch.domains.conversation import Conversation

conversation_client = Conversation(sinch_client)

Endpoint categories

In the Sinch Python 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:

• message
• app
• contact
• event
• transcoding
• capability
• template
• webhook
• conversation

For example:

conversation_response = sinch_client.conversation.message.send(
                    app_id="YOUR_app_ID",
                    recipient={
                        "identified_by" : {
                            "channel_identities" : [
                                {"identity":"RECIPIENT_number","channel" : "SMS"}
                            ]
                        }
                    },
                    message={
                        "text_message" : {
                            "text" : "Text message from Sinch Conversation API."
                        }
                    },
                    channel_properties={
                        "SMS_SENDER" : "YOUR_sms_sender"
                    }
                )

message endpoint category

The message category of the Python SDK corresponds to the messages endpoint. The mapping between the API operations and corresponding Python methods are described below:

app endpoint category

The app category of the Python SDK corresponds to the apps endpoint. The mapping between the API operations and corresponding Python methods are described below:

contact endpoint category

The contact category of the Python SDK corresponds to the contacts endpoint. The mapping between the API operations and corresponding Python methods are described below:

conversation endpoint category

The conversation category of the Python SDK corresponds to the conversations endpoint. The mapping between the API operations and corresponding Python methods are described below:

event endpoint category

The event category of the Python SDK corresponds to the events endpoint. The mapping between the API operations and corresponding Python methods are described below:

transcoding endpoint category

The transcoding category of the Python SDK corresponds to the messages:transcode endpoint. The mapping between the API operations and corresponding Python methods are described below:

capability endpoint category

The capability category of the Python SDK corresponds to the capability endpoint. The mapping between the API operations and corresponding Python methods are described below:

webhook endpoint category

The webhook category of the Python SDK corresponds to the webhooks endpoint. The mapping between the API operations and corresponding Python methods are described below:

template endpoint category

The template category of the Python SDK corresponds to the templates endpoint. The mapping between the API operations and corresponding Python methods are described below:

Request and query parameters

Requests and queries made using the Python SDK are similar to those made using the Conversation API. Many of the fields are named and structured similarly. In most cases, they are the same. For example, consider the representations of a Conversation API app ID below. One field is represented in JSON, and the other is using our Python SDK:

app_id = "{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 python method. For example, consider this example in which the get method of the message class is invoked:

conversation_response = sinch_client.conversation.message.get(
                    message_id="YOUR_message_id"
                    messages_source="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 Python SDK, both parameters are included as arguments in the get method.

Field name differences

Below is a table detailing field names present in the Conversation API and their modified counterparts in the Conversation API Python SDK:

Nested objects

When making calls directly to the API, we use JSON objects, including (in some cases) nested JSON objects. When using the Python SDK, we use dictionaries instead of nested JSON objects. For example, consider the message objects below. One is represented in JSON, the other as a Python dictionary:

message = {
    "text_message": {
        "text": "Text message from Sinch Conversation API."
    }
}

Note that, in both cases, the text_message and text objects are structured in exactly the same way as they would be in a normal Python call to the Conversation API. When using the Python SDK, any argument that represents a nested JSON object will be represented as a Python dictionary at the top level, but the contents of that dictionary must be represented as JSON objects. This is also highlighted in the below example:

recipient={
    "identified_by" : {
        "channel_identities" : [
            {"identity":"RECIPIENT_number","channel" : "SMS"}
        ]
    }
}

Responses

Response fields match the API responses. They are delivered as Python objects, with each top-level field represented as a property. Note that any nested objects normally returned by the Conversation API are returned as dictionaries by the Python SDK.

Voice Domain

The code sample below is an example of how to use the Python SDK to to make a text to speech phone call to a phone number. We've also provided an example that accomplishes the same task using the REST API.

from sinch import SinchClient

sinch_client = SinchClient(
    application_key="YOUR_application_key",
    application_secret="YOUR_application_secret"
)

response = sinch_client.voice.callouts.text_to_speech(
    destination={
        "type":"number",
        "endpoint":"YOUR_phone_number"
    }, 
    text="Hello, this is a call from Sinch. Congratulations! You made your first call.")

print(response)

The Sinch Python SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, sinch_client.voice.[endpoint_category].[method]. You can also create a domain-specific client from a general client. For example:

from sinch import Client
from sinch.domains.voice import Voice

sinch_client = Client(
    application_key="YOUR_application_key",
    application_secret="YOUR_application_secret"
)

voice_client = Voice(sinch_client)

Endpoint categories

In the Sinch Python SDK, Voice API endpoints are accessible through the client (either a general client or a Voice-specific client). The naming convention of the endpoint's representation in the SDK matches the API:

• callouts
• calls
• conferences
• applications

For example:

voice_response = sinch_client.voice.callouts.text_to_speech(
    destination={
        "type":"number",
        "endpoint":"YOUR_phone_number"
    },
    text="This is a text to speech message."
) 

callouts endpoint category

The callouts category of the Python SDK corresponds corresponds to the callouts endpoint. The mapping between the API operations and corresponding Python methods are described below:

calls endpoint category

The calls category of the Python SDK corresponds corresponds to the calls endpoint. The mapping between the API operations and corresponding Python methods are described below:

conferences endpoint category

The conferences category of the Python SDK corresponds corresponds to the conferences endpoint. The mapping between the API operations and corresponding Python methods are described below:

applications endpoint category

The applications category of the Python SDK corresponds corresponds to the configuration endpoint. The mapping between the API operations and corresponding Python methods are described below:

Request and query parameters

Requests and queries made using the Python SDK are similar to those made using the Voice API. Many of the fields are named and structured similarly.

There are some important distinctions to note. For example, consider SVAML actions. In the REST API, SVAML actions must be written in JSON notation, as in the following example:

"action": {
    "name": "hangup"
}

But in the Python SDK, this is an object sent as a simple dict, as demonstrated by the following example:

"action": HangupAction().as_dict()

Field name differences

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

Nested objects

When making calls directly to the API, we use JSON objects, including (in some cases) nested JSON objects. When using the Python SDK, we use dictionaries instead of nested JSON objects. For example, consider the callout destination configuration objects below. One is represented in JSON, the other as a Python dictionary:

destination= {
    "type": "number",
    "endpoint": "YOUR_phone_number"
}

Note that, in both cases, the destination object is structured in exactly the same way as they would be in a normal Python call to the Voice API. When using the Python SDK, any argument that represents a nested JSON object will be represented as a Python dictionary at the top level, but the contents of that dictionary must be represented as JSON objects.

Responses

Response fields match the API responses. They are delivered as Python objects, with each top-level field represented as a property. Note that any nested objects normally returned by the Voice API are returned as dictionaries by the Python SDK. Additionally, if there are any responses that differ significantly from the API responses, we note them in the endpoint category documentation.

Verification Domain

The code sample below is an example of how to use the Python SDK to initiate an SMS PIN 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 Python SDK. 
from sinch import SinchClient
from sinch.domains.verification.models import VerificationIdentity

sinch_client = SinchClient(
    application_key="YOUR_application_key",
    application_secret="YOUR_application_secret"
)

response = sinch_client.verification.verifications.start_sms(
    identity=VerificationIdentity(
        type="number",
        endpoint="YOUR_phone_number"
    )
) 
print(response)

The Sinch Python SDK organizes different functionalities in the Sinch product suite into domains. These domains are accessible through the client. For example, sinch_client.verification.[endpoint_category].[method]. You can also create a domain-specific client from a general client. For example:

from sinch import SinchClient
from sinch.domains.verification import Verification

sinch_client = SinchClient(
    application_key="YOUR_application_key",
    application_secret="YOUR_application_secret"
)

verification_client = Verification(sinch_client)

Endpoint categories

In the Sinch Python SDK, Verification API endpoints are accessible through the client (either a general client or a Verification-specific client). The naming convention of the endpoint's representation in the SDK matches the API:

• verifications
• verification_status

For example:

verification_response = sinch_client.verification.verifications.start_sms(
    identity=VerificationIdentity(
        type="number",
        endpoint="YOUR_phone_number"
    )
) 

verifications endpoint category

The verifications category of the Python SDK corresponds to the verifications endpoint. The mapping between the API operations and corresponding Python methods are described below:

verification_status endpoint category

The verification_status category of the Python SDK corresponds to the verifications endpoint. The mapping between the API operations and corresponding Python methods are described below:

Request and query parameters

Requests and queries made using the Python SDK are similar to those made using the Verification API. Many of the fields are named and structured similarly.

There are some important distinctions to note. For example, consider the VerificationIdentity method. In the REST API, identity is an object you populated with a type string field and an endpoint string field. But in the Python SDK this is a method and you pass the necessary fields as parameters, as demonstrated by the following example:

identity=VerificationIdentity(type="number",endpoint="YOUR_phone_number")

Field name differences

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

Nested objects

When making calls directly to the API, we use JSON objects, including (in some cases) nested JSON objects. When using the Python SDK, we use dictionaries instead of nested JSON objects. When using the Python SDK, any argument that represents a nested JSON object will be represented as a Python dictionary at the top level, but the contents of that dictionary must be represented as JSON objects.

Responses

Response fields match the API responses. They are delivered as Python objects, with each top-level field represented as a property. Note that any nested objects normally returned by the Verification API are returned as dictionaries by the Python SDK. Additionally, if there are any responses that differ significantly from the API responses, we note them in the endpoint category documentation.