# Python SDK

The Sinch Python SDK allows you to quickly interact with the  from inside your Python applications. When using the Python SDK, the code representing requests and queries sent to and responses received from the  are structured similarly to those that are sent and received using the .

Important Python SDK links:
The following links are available for your reference:

- [Sinch Python SDK repository](https://github.com/sinch/sinch-sdk-python)
- [Sinch Python SDK releases](https://github.com/sinch/sinch-sdk-python/releases)


## 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](https://dashboard.sinch.com).


```python
from sinch import SinchClient

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

Note
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:


```python
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

Voice API
To start using the SDK, you need to initialize the main client class with your credentials from your Sinch [dashboard](https://dashboard.sinch.com) and additionally add your [Voice app credentials](https://dashboard.sinch.com/voice/apps).


```python
from sinch import SinchClient

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

Note
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:


```python
import os
from sinch import SinchClient

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

Verification API
To start using the SDK, you need to initialize the main client class with your credentials from your Sinch [dashboard](https://dashboard.sinch.com) and additionally add your [Verification app credentials](https://dashboard.sinch.com/verification/apps).


```python
from sinch import SinchClient

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

Note
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:


```python
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

Note:
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](/docs/numbers/api-reference/numbers).

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.

SDK
list_numbers.py
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)
REST API

```Json

import requests

project_id = "YOUR_project_id"
url = "https://numbers.api.sinch.com/v1/projects/" + project_id + "/availableNumbers"

query = {
  "regionCode": "US",
  "type": "LOCAL"
}

response = requests.get(url, params=query, auth=('<username>','<password>'))

data = response.json()
print(data)
```

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:


```Python

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). The naming convention of the endpoint's representation in the SDK matches the API:

- `available`
- `active`
- `regions`


For example:


```Python

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

The `available` category of the Python SDK corresponds to the [availableNumbers](/docs/numbers/api-reference/numbers/available-number/) endpoint. 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](/docs/numbers/api-reference/numbers/available-number/numberservice_rentanynumber) | `rent_any` |
| [Activate a new phone number](/docs/numbers/api-reference/numbers/available-number/numberservice_rentnumber) | `activate` |
| [Search for available phone numbers](/docs/numbers/api-reference/numbers/available-number/numberservice_listavailablenumbers) | `list` |


The `active` category of the Python SDK corresponds to the [activeNumbers](/docs/numbers/api-reference/numbers/active-number/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [List active numbers for a project](/docs/numbers/api-reference/numbers/active-number/numberservice_listactivenumbers) | `list` |
| [Update active number](/docs/numbers/api-reference/numbers/active-number/numberservice_updateactivenumber) | `update` |
| [Retrieve active number](/docs/numbers/api-reference/numbers/active-number/numberservice_getactivenumber) | `get` |
| [Release active number](/docs/numbers/api-reference/numbers/active-number/numberservice_releasenumber) | `release` |


The `regions` category of the Python SDK corresponds to the [availableRegions](/docs/numbers/api-reference/numbers/available-regions/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [List available regions](/docs/numbers/api-reference/numbers/available-regions/) | `list` |


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:

SDK

```Python
region_code = "US"
```

REST API

```JSON
"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 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` | `voice_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:

SDK

```Python
sms_configuration = {
    "servicePlanId": "service_plan_string"
}
```

{

```JSON
"smsConfiguration": {
    "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.

### SMS Domain

 Note:
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](/docs/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.

SDK
send-message.py

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)
REST API

```Json

import requests

servicePlanId = "YOUR_service_plan_id"
apiToken = "YOUR_api_token"
sinchNumber = "YOUR_Sinch_number"
toNumber = "YOUR_recipient_number"
url = "https://us.sms.api.sinch.com/xms/v1/" + servicePlanId + "/batches"

payload = {
  "from": sinchNumber,
  "to": [
    toNumber
  ],
  "body": "Hello from Sinch!"
}

headers = {
  "Content-Type": "application/json",
  "Authorization": "Bearer " + apiToken
}

response = requests.post(url, json=payload, headers=headers)

data = response.json()
print(data)
```

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:


```Python

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:

- `groups`
- `batches`
- `inbounds`
- `delivery_reports`


For example:


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

The `batches` category of the Python SDK corresponds to the [batches](/docs/sms/api-reference/sms/batches/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Send](/docs/sms/api-reference/sms/batches/sendsms) | `send` |
| [List batches](/docs/sms/api-reference/sms/batches/listbatches) | `list` |
| [Dry run](/docs/sms/api-reference/sms/batches/dry_run) | `send_dry_run` |
| [Get a batch message](/docs/sms/api-reference/sms/batches/getbatchmessage) | `get` |
| [Update a batch message](/docs/sms/api-reference/sms/batches/updatebatchmessage) | `update` |
| [Replace a batch](/docs/sms/api-reference/sms/batches/replacebatch) | `replace` |
| [Cancel a batch message](/docs/sms/api-reference/sms/batches/cancelbatchmessage) | `cancel` |
| [Send delivery feedback for a message](/docs/sms/api-reference/sms/batches/deliveryfeedback) | `send_delivery_feedback` |


The `inbounds` category of the Python SDK corresponds to the [inbounds](/docs/sms/api-reference/sms/inbounds/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [List incoming messages](/docs/sms/api-reference/sms/inbounds/listinboundmessages) | `list` |
| [Retrieve inbound message](/docs/sms/api-reference/sms/inbounds/retrieveinboundmessage) | `get` |


The `groups` category of the Python SDK corresponds to the [groups](/docs/sms/api-reference/sms/groups/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [List groups](/docs/sms/api-reference/sms/groups/listgroups) | `list` |
| [Create a group](/docs/sms/api-reference/sms/groups/creategroup) | `create` |
| [Retrieve a group](/docs/sms/api-reference/sms/groups/retrievegroup) | `get` |
| [Update a group](/docs/sms/api-reference/sms/groups/updategroup) | `update` |
| [Replace a group](/docs/sms/api-reference/sms/groups/replacegroup) | `replace` |
| [Delete a group](/docs/sms/api-reference/sms/groups/deletegroup) | `delete` |
| [Get phone numbers for a group](/docs/sms/api-reference/sms/groups/getmembers) | `get_group_phone_numbers` |


The `delivery_reports` category of the Python SDK corresponds to the [delivery_report and delivery_reports](/docs/sms/api-reference/sms/delivery-reports/) endpoints. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Retrieve a delivery report](/docs/sms/api-reference/sms/delivery-reports/getdeliveryreportbybatchid) | `get_for_batch` |
| [Retrieve a recipient delivery report](/docs/sms/api-reference/sms/delivery-reports/getdeliveryreportbyphonenumber) | `get_for_number` |
| [Retrieve a list of delivery reports](/docs/sms/api-reference/sms/delivery-reports/getdeliveryreports) | `list` |


Note:
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:

SDK

```Python
batch_id = "{BATCH_ID}"
```

REST API

```JSON
"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:

SDK

```Python

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

REST API

```JSON

url = "https://us.SMS.api.sinch.com/v1/" + service_plan_id + "/batches/" + 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 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.

Note:
Any field labelled `from` in the API is labelled as `from_` in the Python SDK.

### Conversation Domain

 Note:
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](/docs/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.

SDK
send-message.py
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)
REST API

```Json

import requests
import base64

appId = "YOUR_app_id"
accessKey = "YOUR_key_id"
accessSecret = "YOUR_key_secret"
projectId = "YOUR_project_id"
channel = "SMS"
identity = "RECIPIENT_number"
sender = "YOUR_sms_sender"
url = "https://us.conversation.api.sinch.com/v1/projects/" + projectId + "/messages:send"

data = accessKey + ":" + accessSecret
encodedBytes = base64.b64encode(data.encode("utf-8"))
accessToken = str(encodedBytes, "utf-8")

payload = {
  "app_id": appId,
  "recipient": {
      "identified_by": {
          "channel_identities": [
            {
                "channel": channel,
                "identity": identity
            }  
            ]
      }
  },
  "message": {
      "text_message": {
          "text": "Text message from Sinch Conversation API."
      }
  },
  "channel_properties": {
    "SMS_SENDER": sender
  }  
}

headers = {
  "Content-Type": "application/json",
  "Authorization": "Basic " + accessToken
}

response = requests.post(url, json=payload, headers=headers)

data = response.json()
print(data)
```

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:


```Python

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:

- `message`
- `app`
- `contact`
- `event`
- `transcoding`
- `capability`
- `template`
- `webhook`
- `conversation`


For example:


```Python

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"
                    }
                )
```

The `message` category of the Python SDK corresponds to the [messages](/docs/conversation/api-reference/conversation/messages/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Send a message](/docs/conversation/api-reference/conversation/messages/messages_sendmessage) | `send` |
| [Get a message](/docs/conversation/api-reference/conversation/messages/messages_getmessage) | `get` |
| [Delete a message](/docs/conversation/api-reference/conversation/messages/messages_deletemessage) | `delete` |
| [List messages](/docs/conversation/api-reference/conversation/messages/messages_listmessages) | `list` |


The `app` category of the Python SDK corresponds to the [apps](/docs/conversation/api-reference/conversation/app/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [List all apps for a given project](/docs/conversation/api-reference/conversation/app/app_listapps) | `list` |
| [Create an app](/docs/conversation/api-reference/conversation/app/app_createapp) | `create` |
| [Get an app](/docs/conversation/api-reference/conversation/app/app_getapp) | `get` |
| [Delete an app](/docs/conversation/api-reference/conversation/app/app_deleteapp) | `delete` |
| [Update an app](/docs/conversation/api-reference/conversation/app/app_updateapp) | `update` |


The `contact` category of the Python SDK corresponds to the [contacts](/docs/conversation/api-reference/conversation/contact/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [List contacts](/docs/conversation/api-reference/conversation/contact/contact_listcontacts) | `list` |
| [Create a contact](/docs/conversation/api-reference/conversation/contact/contact_createcontact) | `create` |
| [Get a contact](/docs/conversation/api-reference/conversation/contact/contact_getcontact) | `get` |
| [Delete a contact](/docs/conversation/api-reference/conversation/contact/contact_deletecontact) | `delete` |
| [Update a contact](/docs/conversation/api-reference/conversation/contact/contact_updatecontact) | `update` |
| [Merge two contacts](/docs/conversation/api-reference/conversation/contact/contact_mergecontact) | `merge` |
| [Get channel profile](/docs/conversation/api-reference/conversation/contact/contact_getchannelprofile) | `get_channel_profile` |


The `conversation` category of the Python SDK corresponds to the [conversations](docs/conversation/api-reference/conversation/conversation/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [List conversations](/docs/conversation/api-reference/conversation/conversation/conversation_listconversations) | `list` |
| [Create a conversation](/docs/conversation/api-reference/conversation/conversation/conversation_createconversation) | `create` |
| [Get a conversation](/docs/conversation/api-reference/conversation/conversation/conversation_getconversation) | `get` |
| [Delete a conversation](/docs/conversation/api-reference/conversation/conversation/conversation_deleteconversation) | `delete` |
| [Update a conversation](/docs/conversation/api-reference/conversation/conversation/conversation_updateconversation) | `update` |
| [Stop conversation](/docs/conversation/api-reference/conversation/conversation/conversation_stopactiveconversation) | `stop` |
| [Inject messages](/docs/conversation/api-reference/conversation/conversation/conversation_injectmessage) | `inject_message_to_conversation` |


The `event` category of the Python SDK corresponds to the [events](/docs/conversation/api-reference/conversation/events/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Send an event](/docs/conversation/api-reference/conversation/events/events_sendevent) | `send` |


The `transcoding` category of the Python SDK corresponds to the [messages:transcode](/docs/conversation/api-reference/conversation/transcoding/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Transcode a message](/docs/conversation/api-reference/conversation/transcoding/transcoding_transcodemessage) | `transcode_message` |


The `capability` category of the Python SDK corresponds to the [capability](/docs/conversation/api-reference/conversation/capability/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Capability lookup](/docs/conversation/api-reference/conversation/capability/capability_querycapability) | `query` |


The `webhook` category of the Python SDK corresponds to the [webhooks](/docs/conversation/api-reference/conversation/webhooks/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [List webhooks](/docs/conversation/api-reference/conversation/webhooks/webhooks_listwebhooks) | `list` |
| [Create a new webhook](/docs/conversation/api-reference/conversation/webhooks/webhooks_createwebhook) | `create` |
| [Get a webhook](/docs/conversation/api-reference/conversation/webhooks/webhooks_getwebhook) | `get` |
| [Update an existing webhook](/docs/conversation/api-reference/conversation/webhooks/webhooks_updatewebhook) | `update` |
| [Delete an existing webhook](/docs/conversation/api-reference/conversation/webhooks/webhooks_deletewebhook) | `delete` |


The `template` category of the Python SDK corresponds to the [templates](/docs/conversation/api-reference/template/templates-v1/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [List all templates belonging to a project ID](/docs/conversation/api-reference/template/templates-v1/templates_listtemplates) | `list` |
| [Creates a template](/docs/conversation/api-reference/template/templates-v1/templates_createtemplate) | `create` |
| [Updates a template](/docs/conversation/api-reference/template/templates-v1/templates_updatetemplate) | `update` |
| [Get a template](/docs/conversation/api-reference/template/templates-v1/templates_gettemplate) | `get` |
| [Delete a template](/docs/conversation/api-reference/template/templates-v1/templates_deletetemplate) | `delete` |


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:

SDK

```Python
app_id = "{APP_ID}"
```

REST API

```JSON
"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:

SDK

```Python

conversation_response = sinch_client.conversation.message.get(
                    message_id="YOUR_message_id"
                    messages_source="CONVERSATION_SOURCE")
```

REST API

```JSON

url = "https://us.conversation.api.sinch.com/v1/projects/" + project_id + "/messages/" + YOUR_message_id

payload = {
    "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:

SDK

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

REST API

```JSON
"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:

SDK

```Python

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

REST API

```JSON

"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.

### Voice Domain

Note:
This guide describes the syntactical structure of the Python 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](/docs/voice/api-reference/voice).

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.

SDK
app.py
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)
REST API

```python
import requests

key = ""
secret = ""
from_number = ""
to = ""
locale = ""
url = "https://calling.api.sinch.com/calling/v1/callouts"

payload = {
  "method": "ttsCallout",
  "ttsCallout": {
    "cli": from_number,
    "destination": {
      "type": "number",
      "endpoint": to
    },
    "locale": locale,
    "text": "Hello, this is a call from Sinch. Congratulations! You made your first call."
  }
}

headers = {"Content-Type": "application/json"}

response = requests.post(url, json=payload, headers=headers, auth=(key, secret))

data = response.json()
print(data)
```

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:


```Python

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)
```

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:


```Python

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

The `callouts` category of the Python SDK corresponds corresponds to the [callouts](/docs/voice/api-reference/voice/callouts/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Makes a Text-to-speech callout](/docs/voice/api-reference/voice/callouts/callouts#callouts/callouts/request) | `text_to_speech()` |
| [Makes a Conference callout](/docs/voice/api-reference/voice/callouts/callouts#callouts/callouts/request) | `conference()` |
| [Makes a Custom callout](/docs/voice/api-reference/voice/callouts/callouts#callouts/callouts/request) | `custom()` |


The `calls` category of the Python SDK corresponds corresponds to the [calls](/docs/voice/api-reference/voice/calls/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Get information about a call](/docs/voice/api-reference/voice/calls/calling_getcallresult) | `get()` |
| [Manage call with `callLeg`](/docs/voice/api-reference/voice/calls/calling_managecallwithcallleg) | `manage_with_call_leg()` |
| [Updates a call in progress](/docs/voice/api-reference/voice/calls/calling_updatecall) | `update()` |


The `conferences` category of the Python SDK corresponds corresponds to the [conferences](/docs/voice/api-reference/voice/conferences/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Get information about a conference](/docs/voice/api-reference/voice/conferences/calling_getconferenceinfo) | `get()` |
| [Makes a Conference callout](/docs/voice/api-reference/voice/callouts/callouts#callouts/callouts/t=request&path=&d=0/conferencecallout) | `call()` |
| [Manage a conference participant](/docs/voice/api-reference/voice/conferences/calling_manageconferenceparticipant) | `manage_participant()` |
| [Remove a participant from a conference](/docs/voice/api-reference/voice/conferences/calling_kickconferenceparticipant) | `kick_participant()` |
| [Remove all participants from a conference](/docs/voice/api-reference/voice/conferences/calling_kickconferenceall) | `kick_all()` |


The `applications` category of the Python SDK corresponds corresponds to the [configuration](/docs/voice/api-reference/voice/applications/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Return all the numbers assigned to an application](/docs/voice/api-reference/voice/applications/configuration_getnumbers) | `get_numbers()` |
| [Assign a number or list of numbers to an application](/docs/voice/api-reference/voice/applications/configuration_updatenumbers) | `assign_numbers()` |
| [Unassign a number from an application](/docs/voice/api-reference/voice/applications/configuration_unassignnumber) | `unassign_number()` |
| [Return the callback URLs for an application](/docs/voice/api-reference/voice/applications/configuration_getcallbackurls) | `get_callback_urls()` |
| [Update the callback URL for an application](/docs/voice/api-reference/voice/applications/configuration_updatecallbackurls) | `update_callback_urls()` |
| [Returns information about a number](/docs/voice/api-reference/voice/applications/calling_querynumber) | `query_number()` |


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:


```json
"action": {
    "name": "hangup"
}
```

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


```python
"action": HangupAction().as_dict()
```

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.

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:

SDK

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

JSON

```JSON
"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.

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

Note:
This guide describes the syntactical structure of the Python 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](/docs/verification/api-reference/verification).

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.

SDK
initiate_sms_verification.py
#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)
REST API

```python
import requests

applicationKey = "<REPLACE_WITH_APP_KEY>"
applicationSecret = "<REPLACE_WITH_APP_SECRET>"
to_number = '<REPLACE_WITH_YOUR_NUMBER>'

sinchVerificationUrl = "https://verification.api.sinch.com/verification/v1/verifications"

payload = {
    "identity": {
        "type": "number",
        "endpoint": to_number
    },
    "method": "sms"
}

headers = {"Content-Type": "application/json"}

response = requests.post(
    sinchVerificationUrl, 
    json=payload, 
    headers=headers, 
    auth=(applicationKey, applicationSecret)
)

data = response.json()
print(data)
```


```python
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:


```Python

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)
```

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:


```Python

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

The `verifications` category of the Python SDK corresponds to the [verifications](/docs/verification/api-reference/verification/verifications-start/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Start an SMS verification request](/docs/verification/api-reference/verification/verifications-start/startverification) | `start_sms()` |
| [Start a FlashCall verification request](/docs/verification/api-reference/verification/verifications-start/startverification) | `start_flash_call()` |
| [Start a phone call verification request](/docs/verification/api-reference/verification/verifications-start/startverification) | `start_callout()` |
| [Start a data verification request](/docs/verification/api-reference/verification/verifications-start/startverification) | `start_seamless()` |
| [Report a verification code by the identity of the recipient](/docs/verification/api-reference/verification/verifications-report/reportverificationbyidentity) | `report_by_identity()` |
| [Report a verification code by the ID of the verification request](/docs/verification/api-reference/verification/verifications-report/reportverificationbyid) | `report_by_id()` |


The `verification_status` category of the Python SDK corresponds to the [verifications](/docs/verification/api-reference/verification/verification-status/) endpoint. The mapping between the API operations and corresponding Python methods are described below:

| API operation | SDK method |
|  --- | --- |
| [Get the status of a verification by the ID of the verification request](/docs/verification/api-reference/verification/verification-status/verificationstatusbyid) | `get_by_id()` |
| [Get the status of a verification by the identity of the recipient](/docs/verification/api-reference/verification/verification-status/verificationstatusbyidentity) | `get_by_identity()` |
| [Get the status of a verification by a reference value](/docs/verification/api-reference/verification/verification-status/verificationstatusbyreference) | `get_by_reference()` |


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:


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

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.

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.

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.