<a id="cc-azure-cosmos-sink"></a>

# Azure Cosmos DB Sink Connector [Deprecated] for Confluent Cloud

#### IMPORTANT
This connector is deprecated and will reach its end of life (EOL) on April 6, 2027.
Confluent recommends migrating to [Azure Cosmos DB Sink V2 connector](cc-azure-cosmos-sink-v2.md#cc-azure-cosmos-v2-sink) before the EOL date.
For more information, see [Deprecated and end of life connectors](overview.md#deprecated-connectors).

The fully managed Azure Cosmos DB Sink connector for Confluent Cloud writes data to a
Microsoft Azure Cosmos database. The connector polls data from Apache Kafka® and  writes to
database containers.

Confluent Cloud is available through [Azure Marketplace](https://azuremarketplace.microsoft.com/en/marketplace/apps/confluentinc.confluent-cloud-azure-prod?tab=Overview)
or [directly from Confluent](https://www.confluent.io/get-started/).

#### NOTE
If you require private networking for fully managed connectors, make sure to set up the proper
networking beforehand. For more information, see [Manage Networking for Confluent Cloud Connectors](networking/internet-resource.md#clusters-connect-cloud).

## Features

The Azure Cosmos DB Sink connector supports the following features:

* **Topic mapping**: Maps the Kafka Topic to the Azure Cosmos DB container.
* **Multiple key strategies**:
  - `FullKeyStrategy`: The ID generated is the Kafka record key. This is the default option.
  - `KafkaMetadataStrategy`: The ID generated is a concatenation of the Kafka topic, partition, and offset. For example: `${topic}-${partition}-${offset}`.
  - `ProvidedInKeyStrategy`: The ID generated is the `id` field found in the key object.
  - `ProvidedInValueStrategy`: The ID generated is the `id` field found in the value object. Every record must have (lower case) `id` field. This is an Azure Cosmos DB requirement. See the [lower case id prerequisite](#cc-azure-cosmos-sink-prereqs).

<a id="cc-azure-cosmos-sink-id-strategy"></a>

The following shows an example of each strategy and the resulting `id` in Azure Cosmos.

![ID Strategies](images/ccloud-azure-cosmos-sink-id-strategies.png)

For more information and examples to use with the Confluent Cloud API for Connect,
see the [Confluent Cloud API for Connect Usage Examples](connect-api-section.md#ccloud-connect-api) section.

## Limitations

Be sure to review the following information.

* For connector limitations, see [Azure Cosmos DB Sink Connector](limits.md#azure-cosmos-sink-limits) limitations.
* If you plan to use one or more Single Message Transformations (SMTs), see [SMT Limitations](single-message-transforms.md#cc-single-message-transforms-limitations).

## Quick Start

Use this quick start to get up and running with the Confluent Cloud Azure Cosmos DB Sink
connector. The quick start provides the basics of selecting the connector and
configuring it to stream Kafka events to an Azure Cosmos DB container.

<a id="cc-azure-cosmos-sink-prereqs"></a>

Prerequisites
: - Authorized access to a [Confluent Cloud](https://www.confluent.io/confluent-cloud/) cluster on Azure.
  - The Confluent CLI installed and configured for the cluster. See [Install the Confluent CLI](https://docs.confluent.io/confluent-cli/current/install.html).
  - [Schema Registry](../get-started/schema-registry.md#cloud-sr-config) must be enabled to use a Schema Registry-based format (for example, Avro, JSON_SR (JSON Schema), or Protobuf).
  - At least one source Kafka topic must exist in your Confluent Cloud cluster before creating the sink connector.
  - The Azure Cosmos DB and the Kafka cluster must be in the same region.
  - The Azure Cosmos DB requires an `id` field in every record. See [ID strategies](#cc-azure-cosmos-sink-id-strategy) for an example of how each of these works. The following strategies are provided to generate the ID:
    * `FullKeyStrategy`: The ID generated is the Kafka record key. This is the default option.
    * `KafkaMetadataStrategy`: The ID generated is a concatenation of the Kafka topic, partition, and offset. For example: `${topic}-${partition}-${offset}`.
    * `ProvidedInKeyStrategy`: The ID generated is the `id` field found in the key object.
    * `ProvidedInValueStrategy`: The ID generated is the `id` field found in the value object. If you select this ID strategy, you must create a new field named `id`. You can also use the following [ksqlDB statement](/platform/current/ksqldb/developer-guide/ksqldb-reference/create-stream.html). The example below uses a topic named `orders`.
      ```sql
      CREATE STREAM ORDERS_STREAM WITH (
         KAFKA_TOPIC = 'orders',
         VALUE_FORMAT = 'AVRO'
         );
      CREATE STREAM ORDER_AUGMENTED AS
         SELECT
            ORDERID AS `id`,
              ORDERTIME,
              ITEMID,
              ORDERUNITS,
              ADDRESS
         FROM  ORDERS_STREAM;
      ```

#### NOTE
* The connector supports `Upsert` based on `id`.
* The connector does not support `Delete` for tombstone records.

### Using the Confluent Cloud Console

#### Step 1: Launch your Confluent Cloud cluster

To create and launch a Kafka cluster in Confluent Cloud, see [Create a kafka cluster in Confluent Cloud](../get-started/index.md#cloud-create-kafka-cluster).

#### Step 2: Add a connector

In the left navigation menu, click **Connectors**. If you already have connectors in your cluster, click **+ Add
connector**.

#### Step 3: Select your connector

Click the **Azure Cosmos DB** sink connector card.

![Azure Cosmos DB Sink Connector Card](images/ccloud-azure-cosmos-sink-icon.png)

<a id="cc-azure-cosmos-sink-setup-connection"></a>

#### Step 4: Enter the connector details

#### NOTE
* Ensure you have all your [prerequisites](#cc-azure-cosmos-sink-prereqs) completed.
* An asterisk ( \* ) designates a required entry.

At the **Add Azure Cosmos DB Sink Connector** screen, complete the following:

### Topic selection

If you’ve already populated your Kafka topics, select the topics you want
to connect from the **Topics** list.

To create a new topic, click **+Add new topic**.

### Kafka access

1. Select the way you want to provide **Kafka Cluster credentials**. You can
   choose one of the following options:
   - **My account**: This setting allows your connector to globally access everything
     that you have access to. With a user account, the connector uses an API key and
     secret to access the Kafka cluster. This option is not recommended for production.
   - **Service account**: This setting limits the access for your connector by using a
     [service account](service-account.md#s3-cloud-service-account). This option is recommended for
     production.
   - **Use an existing API key**: This setting allows you to specify an API key and a
     secret pair. You can use an existing pair or create a new one. This method is not
     recommended for production environments.

   #### NOTE
   Freight clusters support only service accounts for Kafka authentication.
2. Click **Continue**.

### Authentication

1. Configure the authentication properties:
   - **Cosmos Endpoint**: Cosmos endpoint URL. For example,
     `https://connect-cosmosdb.documents.azure.com:443/`.
   - **Cosmos Connection Key**: The Cosmos connection master (primary) key.
   - **Cosmos Database name**: Cosmos target database’s name to write records into.
2. Click **Continue**.

### Configuration

#### NOTE
Configuration properties that are not shown in the
Cloud Console use the default values.  See
[Configuration Properties](#cc-azure-cosmos-sink-config-properties) for all property values
and definitions.

- **Input Kafka record value format**: Select an input Kafka record value format (data coming from the
  Kafka topic). Valid entries are  AVRO, PROTOBUF, JSON_SR (JSON Schema), or JSON (schemaless). A valid
  schema must be available in [Schema Registry](../get-started/schema-registry.md#cloud-sr-config) to use a
  schema-based message format (for example, Avro, JSON_SR (JSON Schema), or
  Protobuf).
- **Topic-Container map**: In the **Topic-Container Map** field, input a comma-delimited list of
  Kafka topics mapped to Cosmos DB containers–the mapping between Kafka
  topics and Azure Cosmos DB containers. For example,
  `topic#container1,topic2#container2`.

### **Show advanced configurations**

- **Schema context**: Select a schema context to use for this connector, if using
  a schema-based data format. This property defaults to the **Default** context,
  which configures the connector to use the default schema set up for Schema Registry in your
  Confluent Cloud environment. A schema context allows you to use separate schemas (like
  schema sub-registries) tied to topics in different Kafka clusters that share the
  same Schema Registry environment. For example, if you select a non-default context, a
  **Source** connector uses only that schema context to register a schema and a
  **Sink** connector uses only that schema context to read from. For more
  information about setting up a schema context, see [What are schema contexts and when should you use them?](../sr/faqs-cc.md#faq-schema-contexts).
- **Id strategy**: The IdStrategy class name to use for generating a
  unique document ID:
  - `FullKeyStrategy`: The ID generated is the Kafka record key.
  - `KafkaMetadataStrategy`: The ID generated is a concatenation
    of the Kafka topic, partition, and offset. For example:
    `${topic}-${partition}-${offset}`.
  - `ProvidedInKeyStrategy`: The ID generated is the `id` field
    found in the key object.
  - `ProvidedInValueStrategy`: The ID generated is the `id`
    field found in the value object. Every record must have (lower
    case) `id` field. This is an Azure Cosmos DB requirement. See
    [Lower case id prerequisite](#cc-azure-cosmos-sink-prereqs).

**Additional Configs**

- **Value Converter Decimal Format**: Specifies the `JSON` or `JSON_SR` serialization format for Connect `DECIMAL` logical type values with two allowed literals:
  `BASE64` to serialize `DECIMAL` logical types as base64 encoded binary data, and
  `NUMERIC` to serialize `DECIMAL` logical type values in `JSON` or `JSON_SR` as a number representing the decimal value.
- **Schema GUID For Key Converter**: Sets the schema GUID to use for deserialization when using `ConfigSchemaIdDeserializer`. This lets you specify a fixed schema GUID for deserializing message keys. This property is applicable only when `key.converter.key.schema.id.deserializer` is set to `ConfigSchemaIdDeserializer`.
- **Value Converter Schema ID Deserializer**: Sets the class name of the schema ID deserializer for values. The deserializer reads schema IDs from message headers.
- **Schema GUID For Value Converter**: Sets the schema GUID to use for deserialization when using `ConfigSchemaIdDeserializer`. This lets you specify a fixed schema GUID for deserializing message values. This property is applicable only when `value.converter.value.schema.id.deserializer` is set to `ConfigSchemaIdDeserializer`.
- **Value Converter Reference Subject Name Strategy**: Sets the subject reference name strategy for values. Valid entries are `DefaultReferenceSubjectNameStrategy` or `QualifiedReferenceSubjectNameStrategy`. You can use this strategy only with `PROTOBUF` format; the default strategy is `DefaultReferenceSubjectNameStrategy`.
- **Schema ID For Value Converter**: Sets the schema ID to use for deserialization when using `ConfigSchemaIdDeserializer`. This lets you specify a fixed schema ID for deserializing message values. This property is applicable only when `value.converter.value.schema.id.deserializer` is set to `ConfigSchemaIdDeserializer`.
- **errors.tolerance**: Use this property if you would like to configure the connector’s error handling behavior. WARNING: This property should be used with CAUTION for SOURCE CONNECTORS as it may lead to dataloss. If you set this property to ‘all’, the connector will not fail on errant records, but will instead log them (and send to DLQ for Sink Connectors) and continue processing. If you set this property to ‘none’, the connector task will fail on errant records.
- **Value Converter Connect Meta Data**: Enables the Connect converter to add its metadata to the output schema. Applies to Avro converters.
- **Value Converter Value Subject Name Strategy**: Determines how to construct the subject name under which the value schema is registered with Schema Registry.
- **Key Converter Key Subject Name Strategy**: Determines how to construct the subject name for key schema registration.
- **Key Converter Schema ID Deserializer**: Sets the class name of the schema ID deserializer for keys. The deserializer reads schema IDs from message headers.
- **Schema ID For Key Converter**: Sets the schema ID to use for deserialization when using `ConfigSchemaIdDeserializer`. This lets you specify a fixed schema ID for deserializing message keys. This property is applicable only when `key.converter.key.schema.id.deserializer` is set to `ConfigSchemaIdDeserializer`.

**Auto-restart policy**

- **Enable Connector Auto-restart**: Enables the auto-restart behavior of the connector and its
  task in the event of user-actionable errors. Defaults to `true`, enabling the connector to
  automatically restart in case of user-actionable errors. Set this property to `false` to
  disable auto-restart for failed connectors. If disabled, you must manually restart the connector.

**Consumer configuration**

- **Max poll interval(ms)**: Sets the maximum delay between subsequent consume requests to Kafka. Use this property to
  improve connector performance in cases when the connector cannot send records to the sink system.
  The default is 300,000 milliseconds (5 minutes).
- **Max poll records**: Sets the maximum number of records to consume from Kafka in a single request. Use this property to
  improve connector performance in cases when the connector cannot send records to the sink system.
  The default is 500 records.

**Transforms**

- **Single Message Transformations**: To add a new SMT, see [Add transforms](single-message-transforms.md#cc-single-message-transforms-ui).
  For more information about unsupported SMTs, see
  [Unsupported transformations](single-message-transforms.md#cc-single-message-transforms-unsupported-transforms).

**Processing position**

- **Set offsets**: Click **Set offsets** to define a specific offset for
  this connector to begin procession data from. For more information
  on managing offsets, see [Manage offsets](offsets.md#connect-custom-offsets).

See [Configuration Properties](#cc-azure-cosmos-sink-config-properties) for all property
values and definitions.

- Click **Continue**.

### Sizing

Based on the number of topic partitions you select, you will be provided
with a recommended number of tasks.

1. To change the number of recommended tasks, enter the number of
   [tasks](/platform/current/connect/concepts.html#tasks) for the connector to use
   in the **Tasks** field. More tasks may improve performance.
2. Click **Continue**.

### Review and Launch

1. Verify the connection details.
2. Click **Launch**.

   The status for the connector should go from **Provisioning** to
   **Running**.

#### Step 5: Check for records

Verify that records are being produced in your Azure Cosmos database.

For more information and examples to use with the Confluent Cloud API for Connect,
see the [Confluent Cloud API for Connect Usage Examples](connect-api-section.md#ccloud-connect-api) section.

### Using the Confluent CLI

Complete the following steps to set up and run the connector using the Confluent CLI.

#### NOTE
Make sure you have all your [prerequisites](#cc-azure-cosmos-sink-prereqs) completed.

#### Step 1: List the available connectors

Enter the following command to list available connectors:

```none
confluent connect plugin list
```

#### Step 2: List the connector configuration properties

Enter the following command to show the connector configuration properties:

```none
confluent connect plugin describe <connector-plugin-name>
```

The command output shows the required and optional configuration properties.

<a id="cc-azure-cosmos-sink-cli-configuration-file"></a>

#### Step 3: Create the connector configuration file

Create a JSON file that contains the connector configuration properties. The following example shows the required connector properties.

```json
{
  "name": "CosmosDbSinkConnector_0",
  "config": {
    "connector.class": "CosmosDbSink",
    "name": "CosmosDbSinkConnector_0",
    "input.data.format": "AVRO",
    "kafka.auth.mode": "KAFKA_API_KEY",
    "kafka.api.key": "****************",
    "kafka.api.secret": "**********************************************",
    "topics": "pageviews",
    "connect.cosmos.connection.endpoint": "https://myaccount.documents.azure.com:443/",
    "connect.cosmos.master.key": "****************************************",
    "connect.cosmos.databasename": "myDBname",
    "connect.cosmos.containers.topicmap": "pageviews#Container2",
    "cosmos.id.strategy": "FullKeyStrategy",
    "tasks.max": "1"
  }
}
```

Note the following property definitions:

* `"connector.class"`: Identifies the connector plugin name.
* `"input.data.format"`:  Sets the input Kafka record value format (data coming from the Kafka topic). Valid entries are **AVRO**, **JSON_SR**, **PROTOBUF**, or **JSON**. You must have Confluent Cloud Schema Registry configured if using a schema-based message format (for example, Avro, JSON_SR (JSON Schema), or Protobuf).
* `"name"`: Sets a name for your new connector.

* `"kafka.auth.mode"`: Identifies the connector authentication mode you want to use. There are two options: `SERVICE_ACCOUNT` or `KAFKA_API_KEY` (the default). To use an API key and secret, specify the configuration properties `kafka.api.key` and `kafka.api.secret`, as shown in the example configuration (above).  To use a [service account](service-account.md#s3-cloud-service-account), specify the **Resource ID** in the property `kafka.service.account.id=<service-account-resource-ID>`. To list the available service account resource IDs, use the following command:
  ```bash
  confluent iam service-account list
  ```

  For example:
  ```bash
  confluent iam service-account list

     Id     | Resource ID |       Name        |    Description
  +---------+-------------+-------------------+-------------------
     123456 | sa-l1r23m   | sa-1              | Service account 1
     789101 | sa-l4d56p   | sa-2              | Service account 2
  ```

* `"connect.cosmos.connection.endpoint"`: A URI with the form `https://ccloud-cosmos-db-1.documents.azure.com:443/`.
* `"connect.cosmos.master.key"`: The Azure Cosmos master key.
* `"connect.cosmos.databasename"`: The name of your Cosmos DB.
* `"connect.cosmos.containers.topicmap"`: A comma-delimited list of Kafka topics mapped to Cosmos DB containers. Note that this property only supports 1:1 mapping between topic and container name. For example: `topic#container1,topic2#container2`.
* (Optional) `"cosmos.id.strategy"`: Defaults to `FullKeyStrategy`. Enter one of the following strategies:
  - `FullKeyStrategy`: The ID generated is the Kafka record key.
  - `KafkaMetadataStrategy`: The ID generated is a concatenation of the Kafka topic, partition, and offset. For example: `${topic}-${partition}-${offset}`.
  - `ProvidedInKeyStrategy`: The ID generated is the `id` field found in the key object. Every record must have (lower case) `id` field. This is an Azure Cosmos DB requirement. See [Lower case id prerequisite](#cc-azure-cosmos-sink-prereqs).
  - `ProvidedInValueStrategy`: The ID generated is the `id` field found in the value object. Every record must have (lower case) `id` field. This is an Azure Cosmos DB requirement. See [Lower case id prerequisite](#cc-azure-cosmos-sink-prereqs).

  See [ID strategies](#cc-azure-cosmos-sink-id-strategy) for an example of how each of these works.
* `"tasks"`: The number of [tasks](/platform/current/connect/concepts.html#tasks) to
  use with the connector. More tasks may improve performance.

**SMTs**: For details about adding SMTs using the Confluent CLI, see the [Single Message Transformations](single-message-transforms.md#cc-single-message-transforms) documentation.

See [Configuration Properties](#cc-azure-cosmos-sink-config-properties) for all property values and
descriptions.

#### Step 4: Load the properties file and create the connector

Enter the following command to load the configuration and start the connector:

```none
confluent connect cluster create --config-file <file-name>.json
```

For example:

```none
confluent connect cluster create --config-file azure-cosmos-sink-config.json
```

Example output:

```none
Created connector CosmosDbSinkConnector_0 lcc-do6vzd
```

#### Step 4: Check the connector status.

Enter the following command to check the connector status:

```none
confluent connect cluster list
```

Example output:

```none
ID           |             Name              | Status  | Type | Trace
+------------+-------------------------------+---------+------+-------+
lcc-do6vzd   | CosmosDbSinkConnector_0       | RUNNING | sink |       |
```

#### Step 5: Check for records

..Verify that records are populating the endpoint.

For more information and examples to use with the Confluent Cloud API for Connect,
see the [Confluent Cloud API for Connect Usage Examples](connect-api-section.md#ccloud-connect-api) section.

<a id="cc-azure-cosmos-sink-config-properties"></a>

## Configuration Properties

Use the following configuration properties with the fully managed connector. For
self-managed connector property definitions and other details, see the connector
docs in [Self-managed connectors for Confluent Platform](/platform/current/connect/kafka_connectors.html).

### How should we connect to your data?

`name`
: Sets a name for your connector.
  <br/>
  * Type: string
  * Valid Values: A string at most 64 characters long
  * Importance: high

### Schema Config

`schema.context.name`
: Add a schema context name. A schema context represents an independent scope in Schema Registry. It is a separate sub-schema tied to topics in different Kafka clusters that share the same Schema Registry instance. If not used, the connector uses the default schema configured for Schema Registry in your Confluent Cloud environment.
  <br/>
  * Type: string
  * Default: default
  * Importance: medium

### Input messages

`input.data.format`
: Sets the input Kafka record value format. Valid entries are AVRO, JSON_SR, PROTOBUF, or JSON. Note that you need to have Confluent Cloud Schema Registry configured if using a schema-based message format like AVRO, JSON_SR, and PROTOBUF.
  <br/>
  * Type: string
  * Importance: high

### Kafka Cluster credentials

`kafka.auth.mode`
: Kafka Authentication mode. It can be one of KAFKA_API_KEY or SERVICE_ACCOUNT. It defaults to KAFKA_API_KEY mode, whenever possible.
  <br/>
  * Type: string
  * Valid Values: SERVICE_ACCOUNT, KAFKA_API_KEY
  * Importance: high

`kafka.api.key`
: Kafka API Key. Required when kafka.auth.mode==KAFKA_API_KEY.
  <br/>
  * Type: password
  * Importance: high

`kafka.service.account.id`
: The Service Account that will be used to generate the API keys to communicate with Kafka Cluster.
  <br/>
  * Type: string
  * Importance: high

`kafka.api.secret`
: Secret associated with Kafka API key. Required when kafka.auth.mode==KAFKA_API_KEY.
  <br/>
  * Type: password
  * Importance: high

### Which topics do you want to get data from?

`topics`
: Identifies the topic name or a comma-separated list of topic names.
  <br/>
  * Type: list
  * Importance: high

`errors.deadletterqueue.topic.name`
: The name of the topic to be used as the dead letter queue (DLQ) for messages that result in an error when processed by this sink connector, or its transformations or converters. Defaults to ‘dlq-${connector}’ if not set. The DLQ topic will be created automatically if it does not exist. You can provide `${connector}` in the value to use it as a placeholder for the logical cluster ID.
  <br/>
  * Type: string
  * Default: dlq-${connector}
  * Importance: low

### How should we connect to your Azure Cosmos DB?

`connect.cosmos.connection.endpoint`
: Cosmos endpoint URL. For example: [https://connect-cosmosdb.documents.azure.com:443/](https://connect-cosmosdb.documents.azure.com:443/).
  <br/>
  * Type: string
  * Importance: high

`connect.cosmos.master.key`
: Cosmos connection master (primary) key.
  <br/>
  * Type: password
  * Importance: high

`connect.cosmos.databasename`
: Cosmos target database to write records into.
  <br/>
  * Type: string
  * Importance: high

`connect.cosmos.containers.topicmap`
: A comma delimited list of Kafka topics mapped to Cosmos containers. For example: topic1#con1,topic2#con2.
  <br/>
  * Type: string
  * Importance: high

### Database details

`cosmos.id.strategy`
: The IdStrategy class name to use for generating a unique document id (id). `FullKeyStrategy` uses the full record key as ID. `KafkaMetadataStrategy` uses a concatenation of the kafka topic, partition, and offset as ID, with dashes as separator. i.e. `${topic}-${partition}-${offset}`. `ProvidedInKeyStrategy` and `ProvidedInValueStrategy` use the `id` field found in the key and value objects respectively as ID.
  <br/>
  * Type: string
  * Default: FullKeyStrategy
  * Valid Values: FullKeyStrategy, KafkaMetadataStrategy, ProvidedInKeyStrategy, ProvidedInValueStrategy
  * Importance: low

### Consumer configuration

`max.poll.interval.ms`
: The maximum delay between subsequent consume requests to Kafka. This configuration property may be used to improve the performance of the connector, if the connector cannot send records to the sink system. Defaults to 300000 milliseconds (5 minutes).
  <br/>
  * Type: long
  * Default: 300000 (5 minutes)
  * Valid Values: [60000,…,1800000] for non-dedicated clusters and [60000,…] for dedicated clusters
  * Importance: low

`max.poll.records`
: The maximum number of records to consume from Kafka in a single request. This configuration property may be used to improve the performance of the connector, if the connector cannot send records to the sink system. Defaults to 500 records.
  <br/>
  * Type: long
  * Default: 500
  * Valid Values: [1,…,500] for non-dedicated clusters and [1,…] for dedicated clusters
  * Importance: low

### Number of tasks for this connector

`tasks.max`
: Maximum number of tasks for the connector.
  <br/>
  * Type: int
  * Valid Values: [1,…]
  * Importance: high

### Additional Configs

`key.converter.use.schema.guid`
: The schema GUID to use for deserialization when using ConfigSchemaIdDeserializer. This allows you to specify a fixed schema GUID to be used for deserializing message keys. Only applicable when key.converter.key.schema.id.deserializer is set to ConfigSchemaIdDeserializer.
  <br/>
  * Type: string
  * Importance: low

`key.converter.use.schema.id`
: The schema ID to use for deserialization when using ConfigSchemaIdDeserializer. This allows you to specify a fixed schema ID to be used for deserializing message keys. Only applicable when key.converter.key.schema.id.deserializer is set to ConfigSchemaIdDeserializer.
  <br/>
  * Type: int
  * Importance: low

`value.converter.connect.meta.data`
: Allow the Connect converter to add its metadata to the output schema. Applicable for Avro Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.use.schema.guid`
: The schema GUID to use for deserialization when using ConfigSchemaIdDeserializer. This allows you to specify a fixed schema GUID to be used for deserializing message values. Only applicable when value.converter.value.schema.id.deserializer is set to ConfigSchemaIdDeserializer.
  <br/>
  * Type: string
  * Importance: low

`value.converter.use.schema.id`
: The schema ID to use for deserialization when using ConfigSchemaIdDeserializer. This allows you to specify a fixed schema ID to be used for deserializing message values. Only applicable when value.converter.value.schema.id.deserializer is set to ConfigSchemaIdDeserializer.
  <br/>
  * Type: int
  * Importance: low

`errors.tolerance`
: Use this property if you would like to configure the connector’s error handling behavior. WARNING: This property should be used with CAUTION for SOURCE CONNECTORS as it may lead to dataloss. If you set this property to ‘all’, the connector will not fail on errant records, but will instead log them (and send to DLQ for Sink Connectors) and continue processing. If you set this property to ‘none’, the connector task will fail on errant records.
  <br/>
  * Type: string
  * Default: all
  * Importance: low

`key.converter.key.schema.id.deserializer`
: The class name of the schema ID deserializer for keys. This is used to deserialize schema IDs from the message headers.
  <br/>
  * Type: string
  * Default: io.confluent.kafka.serializers.schema.id.DualSchemaIdDeserializer
  * Importance: low

`key.converter.key.subject.name.strategy`
: How to construct the subject name for key schema registration.
  <br/>
  * Type: string
  * Default: TopicNameStrategy
  * Importance: low

`value.converter.decimal.format`
: Specify the JSON/JSON_SR serialization format for Connect DECIMAL logical type values with two allowed literals:
  <br/>
  BASE64 to serialize DECIMAL logical types as base64 encoded binary data and
  <br/>
  NUMERIC to serialize Connect DECIMAL logical type values in JSON/JSON_SR as a number representing the decimal value.
  <br/>
  * Type: string
  * Default: BASE64
  * Importance: low

`value.converter.reference.subject.name.strategy`
: Set the subject reference name strategy for value. Valid entries are DefaultReferenceSubjectNameStrategy or QualifiedReferenceSubjectNameStrategy. Note that the subject reference name strategy can be selected only for PROTOBUF format with the default strategy being DefaultReferenceSubjectNameStrategy.
  <br/>
  * Type: string
  * Default: DefaultReferenceSubjectNameStrategy
  * Importance: low

`value.converter.value.schema.id.deserializer`
: The class name of the schema ID deserializer for values. This is used to deserialize schema IDs from the message headers.
  <br/>
  * Type: string
  * Default: io.confluent.kafka.serializers.schema.id.DualSchemaIdDeserializer
  * Importance: low

`value.converter.value.subject.name.strategy`
: Determines how to construct the subject name under which the value schema is registered with Schema Registry.
  <br/>
  * Type: string
  * Default: TopicNameStrategy
  * Importance: low

### Auto-restart policy

`auto.restart.on.user.error`
: Enable connector to automatically restart on user-actionable errors.
  <br/>
  * Type: boolean
  * Default: true
  * Importance: medium

## Frequently asked questions

Find answers to frequently asked questions about the Azure Cosmos DB Sink connector for Confluent Cloud.

### How do I configure the connector to write to specific containers?

The connector writes data from Kafka topics to Cosmos DB containers using topic to container mapping.

Container configuration:

1. **One topic to one container**: Map a single topic to a container:
   ```json
   {
     "topics": "orders-topic",
     "connect.cosmos.databasename": "production-db",
     "connect.cosmos.containers.topicmap": "orders-topic#orders-container"
   }
   ```

   Messages from `orders-topic` are written to `orders-container`.
2. **Multiple topics to containers**: Map multiple topics:
   ```json
   {
     "topics": "orders-topic,users-topic",
     "connect.cosmos.containers.topicmap": "orders-topic#orders-container,users-topic#users-container"
   }
   ```

#### IMPORTANT
The topic mapping format must follow the pattern `topic#container`. Multiple mappings are comma-separated. Containers must exist in Cosmos DB before starting the connector.

### Why is my connector failing with write errors?

Write errors can occur due to insufficient permissions, RU throttling, or data validation issues.

```text
Request rate is large. More Request Units may be needed
```

Common causes and solutions:

1. **Insufficient Request Units**: Cosmos DB is throttling writes due to RU limits:

   Increase provisioned throughput or enable autoscale in the Azure portal.

   Monitor Request Unit consumption under **Metrics** in your Cosmos DB account.
2. **Missing partition key**: Documents are missing the required partition key:

   Ensure all records include the partition key field. The partition key is defined when creating the container in Cosmos DB.
3. **Insufficient permissions**: The master key lacks write access:

   Verify the `connect.cosmos.master.key` in the Azure portal under **Keys** in your Cosmos DB account settings.
4. **Document size exceeds limit**: Documents are larger than the 2 MB limit:

   Review and reduce document size. Cosmos DB enforces a 2 MB maximum document size.
5. **Container does not exist**: The target container is not created in Cosmos DB:

   Create the container in the Azure portal before starting the connector.

#### NOTE
Monitor Cosmos DB metrics to optimize throughput allocation. Consider upgrading to the V2 connector for bulk operations and improved performance.

### What Azure Cosmos DB permissions are required for the connector?

The connector requires specific permissions to write data to Cosmos DB.

Required permissions:

1. **Master key access**: The connector uses the master key for authentication:

   Obtain the master key from the Azure portal:

   Navigate to your Cosmos DB account > **Keys** > Copy the `PRIMARY KEY` or `SECONDARY KEY`.
2. **Write permissions**: The master key provides full write access to all containers:

   The connector can write to any container in the specified database.

#### IMPORTANT
Master keys provide full access to the Cosmos DB account. Store keys securely and rotate them periodically. Consider upgrading to the V2 connector for service principal authentication support.

### How can I optimize connector write performance?

Write performance depends on Cosmos DB throughput, connector task configuration, and network latency.

Performance optimization:

1. **Increase tasks**: More tasks can improve write throughput:
   ```json
   {
     "tasks.max": "4"
   }
   ```

   Multiple tasks write to Cosmos DB in parallel.
2. **Optimize Cosmos DB throughput**: Ensure adequate Request Units:
   * **Use autoscale**: Configure autoscale to handle variable workloads
   * **Monitor Request Unit consumption**: Check for throttling
   * **Increase provisioned throughput**: Allocate more Request Units if needed
3. **Use same region**: Deploy the connector in the same Azure region as Cosmos DB:

   Cross-region writes have higher latency and cost more.
4. **Optimize partition key**: Choose a partition key that distributes writes evenly:

   Avoid hot partitions by selecting a high-cardinality partition key.

#### NOTE
Consider upgrading to the V2 connector for bulk operations, which provide significantly better performance than the V1 connector.

### Why is my connector failing with authentication errors?

Authentication errors indicate issues with the master key or account endpoint.

```text
Unauthorized: The input authorization token can't serve the request
```

Common causes and solutions:

1. **Invalid master key**: The `connect.cosmos.master.key` is incorrect:

   Verify the master key in the Azure portal under **Keys** in your Cosmos DB account settings. Ensure you copied the full key including any trailing characters.
2. **Wrong account endpoint**: The endpoint URL is incorrect:

   Verify the endpoint format:
   ```json
   {
     "connect.cosmos.connection.endpoint": "https://your-account.documents.azure.com:443/"
   }
   ```

   The endpoint must include `https://` and port `:443/`.
3. **Regenerated keys**: Keys were regenerated in the Azure portal:

   If keys are rotated, update the connector configuration with the new master key.

#### IMPORTANT
Master keys provide full access to the Cosmos DB account. For enhanced security, consider upgrading to the V2 connector which supports service principal authentication.

### What should I do if my connector keeps failing or restarting?

Frequent connector failures indicate configuration issues, network problems, or Cosmos DB capacity constraints.

Common causes and solutions:

1. **Check connector logs**: In the Cloud Console, review error messages:
   * **Authentication failures**: Verify master key and endpoint
   * **Throttling errors**: Check RU consumption and increase throughput
   * **Validation errors**: Verify document structure and partition keys
   * **Network errors**: Check connectivity
2. **Verify Cosmos DB connectivity**: Test that Cosmos DB is accessible:
   * **Check firewall rules**: Ensure Confluent Cloud can connect to Cosmos DB
   * **Verify endpoint**: Confirm the account endpoint is correct
   * **Test credentials**: Use Azure portal to verify account access
3. **Monitor Cosmos DB metrics**: Check for resource constraints:
   * **Request Unit consumption**: Monitor Request Unit usage and throttling
   * **Storage capacity**: Ensure adequate storage
   * **Partition key distribution**: Check for hot partitions
4. **Verify container configuration**: Ensure containers exist and are accessible:

   Verify containers listed in `connect.cosmos.containers.topicmap` exist in Cosmos DB.

#### IMPORTANT
For persistent failures, use the connector diagnostics feature and share logs with Confluent Support. Consider upgrading to the V2 connector for enhanced features and improved performance.

## Next Steps

For an example that shows fully managed Confluent Cloud connectors in action with
Confluent Cloud for Apache Flink, see the [Cloud ETL Demo](/platform/current/tutorials/examples/cloud-etl/docs/index.html).
This example also shows how to use Confluent CLI to manage your resources in
Confluent Cloud.

[![image](images/topology.png)](https://docs.confluent.io/platform/current/tutorials/examples/cloud-etl/docs/index.html)