# Sinch Python SDK for Numbers 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 . The fastest way to get started with the SDK is to check out our [getting started](/docs/numbers/getting-started/python-sdk/searchavailable) guides. There you'll find all the instructions necessary to download, install, set up, and start using the SDK. ## Syntax 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=('','')) data = response.json() print(data) ``` This example highlights the following required to successfully make a Numbers API call using the Sinch Python SDK: - [Client initialization](#client) - [Numbers domain access](#numbers-domain) - [Endpoint usage](#endpoint-categories) - [Field population](#request-and-query-parameters) ## 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 the functionality of the Sinch Python SDK. ### Initialization 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") ) ``` ## Numbers domain 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.