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.
The following links are available for your reference:
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.
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")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, as in the following example:
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")
)For the SMS API in Australia (AU), Brazil (BR), Canada (CA), the United States (US), and the European Union (EU), provide the following parameters:
from sinch import SinchClient
sinch_client = SinchClient(
service_plan_id="service_plan_id",
sms_api_token="api_token"
)You must set sms_region before using the SMS API and conversation_region before using the Conversation API, either in the SinchClient(...) constructor or on sinch_client.configuration before the first call to that product, as in the following examples:
from sinch import SinchClient
sinch_client = SinchClient(
project_id="your-project-id",
key_id="your-key-id",
key_secret="your-key-secret",
conversation_region="eu",
)
# Note: The conversation_region can also be set through the configuration object,
# but you must ensure this setting is done BEFORE any Conversation API call:
sinch_client.configuration.conversation_region = "eu"The Python SDK currently supports the following products:
This guide describes the syntactical structure of the Python 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 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.
"""
Sinch Python Snippet
This snippet is available at https://github.com/sinch/sinch-sdk-python/tree/main/examples/snippets
"""
import os
from dotenv import load_dotenv
from sinch import SinchClient
load_dotenv()
sinch_client = SinchClient(
project_id=os.environ.get("SINCH_PROJECT_ID") or "MY_PROJECT_ID",
key_id=os.environ.get("SINCH_KEY_ID") or "MY_KEY_ID",
key_secret=os.environ.get("SINCH_KEY_SECRET") or "MY_KEY_SECRET"
)
available_numbers = sinch_client.numbers.search_for_available_numbers(
region_code="AR",
number_type="LOCAL"
)
print("Available numbers to rent:\n")
for number in available_numbers.iterator():
print(number)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)
In the Sinch Python SDK, Numbers API endpoints are accessible through the client (either a general client or a Numbers-specific client).
numbersnumbers.regionsnumbers.event_destinations
For example:
numbers_available = sinch_client.numbers.search_for_available_numbers(
region_code="US",
number_type="LOCAL"
)
The numbers category of the Python SDK corresponds to the available-numbers and active-numbers endpoints. The mapping between the API operations and corresponding Python methods are described below:
| API operation | SDK method |
|---|---|
| Rent the first available number matching the provided criteria | rent_any |
| Activate a new phone number | rent |
| Check availability | check_availability |
| Search for available phone numbers | search_for_available_numbers |
| 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 Python SDK corresponds to the available-regions endpoint. The mapping between the API operations and corresponding Python methods are described below:
| API operation | SDK method |
|---|---|
| List available regions | list |
The numbers.event_destinations category of the Python SDK corresponds to the numbers-callbacks endpoint. The mapping between the API operations and corresponding Python methods are described below:
| API operation | SDK method |
|---|---|
| Get callbacks configuration | get |
| Update callbacks configuration | update |
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.
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:
| API field name | SDK field name |
|---|---|
regionCode | region_code |
type | number_type |
types | number_types |
numberPattern.pattern | number_pattern |
numberPattern.searchPattern | number_search_pattern |
phoneNumber | phone_number |
smsConfiguration | sms_configuration |
capability | capabilities |
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.
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.
This guide describes the syntactical structure of the Python SDK for the Number Lookup API, including any differences that may exist between the API itself and the SDK. For a full reference on Number Lookup API calls and responses, see the Number Lookup API Reference.
The code sample on this page is an example of how to use the Python SDK to look up a phone number. We've also provided an example that accomplishes the same task using the REST API.
"""
Sinch Python Snippet
This snippet is available at https://github.com/sinch/sinch-sdk-python/tree/main/examples/snippets
"""
import os
from dotenv import load_dotenv
from sinch import SinchClient
load_dotenv()
sinch_client = SinchClient(
project_id=os.environ.get("SINCH_PROJECT_ID") or "MY_PROJECT_ID",
key_id=os.environ.get("SINCH_KEY_ID") or "MY_KEY_ID",
key_secret=os.environ.get("SINCH_KEY_SECRET") or "MY_KEY_SECRET",
)
# The phone number to look up in E.164 format (e.g. +1234567890)
phone_number = "PHONE_NUMBER"
response = sinch_client.number_lookup.lookup(number=phone_number)
print(f"Number lookup result:\n{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.number_lookup.[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.number_lookup import NumberLookup
number_lookup_client = NumberLookup(sinch_client)
In the Sinch Python SDK, Number Lookup API endpoints are accessible through the client (either a general client or a Number Lookup-specific client). The naming convention of the endpoint's representation in the SDK matches the API:
lookup
For example:
lookup_number = sinch_client.number_lookup.lookup(number="YOUR_PHONE_NUMBER")
The lookup category of the Python SDK corresponds to the lookup endpoint. The mapping between the API operations and corresponding Python methods are described below:
| API operation | SDK method |
|---|---|
| Look up a phone number | lookup |
Requests and queries made using the Python SDK are similar to those made using the Number Lookup API. Many of the fields are named and structured similarly. For example, consider the representations of a Number Lookup API region code. One field is represented in JSON, and the other is using our Python SDK:
mobile_country_code = "310"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.
When translating field names from the Number Lookup 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 Number Lookup API and their modified counterparts in the Number Lookup API Python SDK:
| API field name | SDK field name |
|---|---|
regionCode | region_code |
type | number_type |
types | number_types |
mobileCountryCode | mobile_country_code |
swapPeriod | swap_period |
phoneNumber | phone_number |
portingDate | porting_date |
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 Number Lookup 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.
This guide describes the syntactical structure of the Python 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 API Reference.
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.
"""
Sinch Python Snippet
This snippet is available at https://github.com/sinch/sinch-sdk-python/tree/main/examples/snippets
"""
import os
from dotenv import load_dotenv
from sinch import SinchClient
load_dotenv()
sinch_client = SinchClient(
project_id=os.environ.get("SINCH_PROJECT_ID") or "MY_PROJECT_ID",
key_id=os.environ.get("SINCH_KEY_ID") or "MY_KEY_ID",
key_secret=os.environ.get("SINCH_KEY_SECRET") or "MY_KEY_SECRET",
sms_region=os.environ.get("SINCH_SMS_REGION") or "MY_SMS_REGION"
)
response = sinch_client.sms.batches.send_sms(
to=["+1234567890"],
from_="+2345678901",
body="Hello, this is a test message!"
)
print(f"Batch sent:\n{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)
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:
sms.batchessms.delivery_reportssms.sinch_events
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"
)The sms.batches category of the Python SDK corresponds to the batches endpoint. The mapping between the API operations and corresponding Python methods are described below:
| API operation | SDK method |
|---|---|
| Send an SMS | send_sms |
| Send an MMS | send_mms |
| Send a binary message | send_binary |
| List batches | list |
| Dry run an SMS | dry_run_sms |
| Dry run an MMS | dry_run_mms |
| Dry run a binary message | dry_run_binary |
| Get a batch message | get |
| Update a batch SMS | update_sms |
| Update a batch MMS | update_mms |
| Update a batch binary message | update_binary |
| Replace an SMS batch | replace_sms |
| Replace an MMS batch | replace_mms |
| Replace a binary batch | replace_binary |
| Cancel a batch message | cancel |
| Send delivery feedback for a message | send_delivery_feedback |
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:
| API operation | SDK method |
|---|---|
| Retrieve a delivery report | get |
| Retrieve a recipient delivery report | get_for_number |
| Retrieve a list of delivery reports | list |
The sms.sinch_events category of the Python SDK contains methods for webhook signature validation.
| API operation | SDK method |
|---|---|
| Validate signature | _validate_signature |
| Validate authentication header | validate_authentication_header |
| Parse event | parse_event |
Note that the service_plan_id path parameter does not need to be included in any requests created by the Python SDK.
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.
Below is a table detailing field names present in the SMS API and their modified counterparts in the SMS API Python SDK:
| API field name | SDK field name |
|---|---|
type | type_ |
from | from_ |
recipient_msisdn | recipient_number |
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.
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.
Any field labelled from in the API is labelled as from_ in the Python SDK.
This guide describes the syntactical structure of the Python 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 API Reference.
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.
"""
Sinch Python Snippet
This snippet is available at https://github.com/sinch/sinch-sdk-python/tree/main/examples/snippets
"""
import os
from dotenv import load_dotenv
from sinch import SinchClient
load_dotenv()
sinch_client = SinchClient(
project_id=os.environ.get("SINCH_PROJECT_ID") or "MY_PROJECT_ID",
key_id=os.environ.get("SINCH_KEY_ID") or "MY_KEY_ID",
key_secret=os.environ.get("SINCH_KEY_SECRET") or "MY_KEY_SECRET",
conversation_region=os.environ.get("SINCH_CONVERSATION_REGION") or "MY_CONVERSATION_REGION"
)
# The ID of the Conversation App to send the message from
app_id = "CONVERSATION_APP_ID"
# The phone number of the recipient in E.164 format (e.g. +46701234567)
recipient_identities = [
{
"channel": "SMS",
"identity": "RECIPIENT_PHONE_NUMBER"
}
]
response = sinch_client.conversation.messages.send_text_message(
app_id=app_id,
text="[Python SDK: Conversation] Sample text message",
recipient_identities=recipient_identities
)
print(f"Successfully sent text message.\n{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)
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:
conversation.messagesconversation.sinch_events
For example:
app_id = "CONVERSATION_APP_ID"
recipient_identities = [
{
"channel": "SMS",
"identity": "RECIPIENT_PHONE_NUMBER"
}
]
response = sinch_client.conversation.messages.send_text_message(
app_id=app_id,
text="[Python SDK: Conversation] Sample text message",
recipient_identities=recipient_identities
)
The conversation.messages category of the Python SDK corresponds to the messages endpoint. The mapping between the API operations and corresponding Python methods are described below:
| API operation | SDK method |
|---|---|
| Send a message | send |
| Get a message | get |
| Delete a message | delete |
| List messages | list |
| Update message metadata | update |
| List messages by channel identity | list_last_messages_by_channel_identity |
Additionally, there are several helper methods for sending messages of the different media types:
| API operation | SDK method |
|---|---|
| Send a card message | send_card_message |
| Send a carousel message | send_carousel_message |
| Send a choice message | send_choice_message |
| Send a contact info message | send_contact_info_message |
| Send a list message | send_list_message |
| Send a location message | send_location_message |
| Send a media message | send_media_message |
| Send a template message | send_template_message |
| Send a text message | send_text_message |
The conversation.sinch_events category of the Python SDK contains methods for webhook signature validation.
| API operation | SDK method |
|---|---|
| Validate signature | _validate_signature |
| Validate authentication header | validate_authentication_header |
| Parse event | parse_event |
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.messages.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.
Below is a table detailing field names present in the Conversation API and their modified counterparts in the Conversation API Python SDK:
| API field name | SDK field name |
|---|---|
metadata_json | conversation_metadata |
update_mask.paths | update_mask |
message.conversation_id | conversation_id |
from | from_ |
default_translation | default_translations |
template.id | template_id |
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"}
]
}
}
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.