<a id="cc-http-sink-v2"></a>

# HTTP Sink V2 Connector for Confluent Cloud

The fully managed HTTP Sink V2 connector for Confluent Cloud connects Apache Kafka® topics
to HTTP or HTTPS APIs. It supports OpenAPI specification-based
configuration for up to 15 API paths, reducing configuration time and
improving performance over the [HTTP Sink Connector for Confluent Cloud](cc-http-sink.md#cc-http-sink).

#### 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 HTTP Sink V2 connector includes the following features:

* **Multiple API path support**: The connector allows you to configure up to 15 API
  paths having the same base URL and authentication mechanism. Each topic can
  be routed to only one API path. If a topic is included in the topics list
  for more than one API path, the connector routes records from that topic to
  the last-configured API path only. For connector
  limitations, see [HTTP Sink V2 Connector](limits.md#http-sink-v2-limits).
* **Upsert support**: The connector supports upsert operations. For more information,
  see [Manage Upserts](#cc-http-sink-v2-upsert).
* **OpenAPI Specification-based configuration**: The connector provides seamless
  configuration through an OpenAPI specification file.
* **Secure access and data exchange**: The connector supports the following
  authentication mechanisms:
  - Basic
  - Bearer
  - OAuth 2.0 Client Credentials grant flow
  - API key (only supported in Confluent CLI)
* **Secret manager integration**: The connector supports secret manager integration. For `Password` based authentication, the connector can retrieve the following configurations from an integrated secret manager at runtime as needed.

  | **Secret manager managed configuration**   | **Type**   |
  |--------------------------------------------|------------|
  | `connection.user`                          | `STRING`   |
  | `connection.password`                      | `PASSWORD` |

  #### NOTE
  Secret manager integration for this connector is currently supported
  only through Confluent Cloud APIs and Confluent CLI. It is not yet available
  through Confluent Cloud Console.

  For more information, see [Create a secret manager integration in Confluent Cloud](secret-manager-integration/overview.md#cloud-secret-manager-quickstart).
* **Client-side field level encryption (CSFLE) support**: The connector supports CSFLE for sensitive data. For more information about CSFLE setup, see the [Manage CSFLE for connectors](csfle.md#connect-csfle).
* **API error reporting management**: You can configure the connector to notify
  you when an API error occurs through email or through the Confluent Cloud user
  interface. You also can configure the connector to ignore when an API error
  occurs.
* **API validation**: The connector allows you to test the API using a
  test record and view the test API response logs in the Confluent Cloud user interface.
* **Template variables**: The connector allows you to specify template
  variables, such as `${topic}` and `${key}`, along with fields from
  the Kafka record for use in an HTTP
  request:
  - Headers
  - Query parameters
  - Path parameters
  - Body parameters

  The connector constructs a unique URL using these parameters and enables
  substitution of template variables in headers, parameters, and body content.
* **Supported data formats**: The connector supports String, Avro, Bytes, JSON
  (schemaless), JSON Schema, and Protobuf data formats. [Schema Registry](../get-started/schema-registry.md#cloud-sr-config) must be enabled to use a Schema Registry-based format like Avro, JSON
  Schema, or Protobuf.
* **Custom offset support**: The connector allows you to configure [custom
  offsets](offsets.md#connect-custom-offsets) using the Confluent Cloud user interface to prevent
  data loss and data duplication.
* **Configurable retry functionality**: The connector allows you to customize
  retry settings based on your requirements.

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.

## Manage CSFLE

If you plan to enable CSFLE for the HTTP Sink V2 connector, take care of the following sensitive information that may get written to your Kafka topics:

#### WARNING
* **Error topic**: The error topic may include sensitive data from the API response.
* **Success topic**: The success topic may include sensitive data from the API response.

<a id="cc-http-sink-v2-upsert"></a>

## Manage Upserts

The connector supports upsert operations using the following API-level configuration properties:

- `upsert.method`: Use this to define the HTTP method for upsert operations. For example, set it to `POST` to enable upsert operations.
- `upsert.api.path`:  Use this to set the API path for upsert operations. The connector sends HTTP requests to this path.
- `upsert.on.field.value`: Use this to specify a field within your Kafka record value to determine whether the connector should update or insert a record.

When an upsert is triggered, the connector sends an HTTP request to the API path specified by `upsert.api.path`, using the HTTP method from `upsert.method`. The connector triggers an upsert in two scenarios:

- If you specify `upsert.on.field.value` (for example, `"jsonPath=expected_value"`), the connector checks the Kafka record value. If the field at `jsonPath` exists and matches `expected_value`, the connector performs an upsert.
- If you do not specify `upsert.on.field.value`, the connector performs an upsert when the Kafka record key is `null` or empty.

## Limitations

Be sure to review the following information.

* For connector limitations, see [HTTP Sink V2 Connector](limits.md#http-sink-v2-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 HTTP Sink V2
connector.

<a id="cc-http-sink-v2-prereqs"></a>

Prerequisites
: - Authorized access to a [Confluent Cloud](https://www.confluent.io/confluent-cloud/) cluster on Amazon Web Services
    (AWS), Microsoft Azure (Azure), or Google Cloud).
  - The Confluent CLI installed and configured for the cluster. For help, 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).
  - OpenAPI Specification file version 3.0.
  - Relevant authentication credentials for both Kafka and your data system.
  - At least one source Kafka topic must exist in your Confluent Cloud cluster before
    creating the Sink connector.

### 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 **HTTP Sink V2** connector card.

![HTTP Sink V2 Connector Card](images/ccloud-http-sink-v2-icon.png)

<a id="cc-http-sink-v2-connection"></a>

#### Step 4: Enter the connector details

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

At the **Add HTTP Sink V2 Connector** screen, complete the following:

### Details

Enter the following details:

1. Provide the connector name in the **Connector name** field.
2. Add the OpenAPI specification file (OAS 3.0 or higher) by adding a URL
   endpoint or by uploading a YAML/JSON formatted specification file. Note
   that you can convert Swagger 1.x or 2.0 definitions to OpenAPI 3.0
   using the [Swagger Converter](https://converter.swagger.io/).
   - To add a URL endpoint, enter the URL in the **Add via URL** field.
     Note that the maximum file size is 3 MB.
   - To upload a YAML/JSON formatted specification file, select **Add a
     file**, then click **Upload file** to upload the file. Note that the
     maximum file size is 1 MB.

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

   **Server Connection**
   - **URL**: Enter your API Base URL in the **URL** field. The HTTP API Base URL. For example: `http://example.com/absenceManagement/v1`.

   **Authentication**
   - **Authentication method**: Authentication type of the endpoint. Valid values are `NONE`, `BASIC`, `OAUTH2` (Client Credentials grant type only), `BEARER`, `API_KEY`. When an OpenAPI spec is provided, this list is narrowed to the auth schemes declared by the spec.
   - **Use secret manager**: Fetch sensitive configuration values from a secret manager.
   - **Secret manager**: Select the secret manager to use for retrieving sensitive data.
   - **Bearer token**: The bearer authentication token to be used with an endpoint requiring bearer token-based authentication.
   - **Provider Integration**: Select an existing provider integration that has access to your secret manager.
   - **Client ID**: The client ID used when fetching the OAuth2 token.
   - **Client secret**: The secret used when fetching the OAuth2 token.
   - **Configurations from Secret manager**: Select the configurations whose values Confluent Cloud should
     fetch from the secret manager.
   - **Client authentication mode**: Specifies how to encode the Client
     ID and Client Secret in the OAuth2 authorization request. If set to
     `header`, the credentials are encoded as an `'Authorization:
     Basic <base-64 encoded client_id:client_secret>'` HTTP header. If
     set to `url`, then Client ID and Client Secret are sent as URL
     encoded parameters.
   - **Auth username**: The username for an endpoint that requires basic authentication.
   - **Scope**: The scope parameter sent when fetching the OAuth2 token.
   - **OAuth2 client headers separator**: Separator character used in OAuth2 client headers. You can only set this configuration using the CLI.
   - **OAuth2 token property name**: The name of the property containing the OAuth2 token returned by the OAuth2 token URL (defaults to `access_token`).
   - **Auth password**: The password for an endpoint that requires basic authentication.
   - **Token server URL**: The URL to be used for fetching the OAuth2 token.
   - **OAuth2 client headers**: HTTP headers to include in the OAuth2 client endpoint. Separate individual headers using `|`. You can only set this configuration using the CLI.
   - **API key location**: Specifies where the API key is included in the HTTP request. Choose `HEADER` to send the API key as an HTTP header (for example, `X-API-KEY: your-api-key`), or `QUERY` to include it as a query parameter in the URL (for example, `?api_key=your-api-key`). The default is `HEADER`, which is the most common and secure approach.
   - **API key name**: The identifier for the API key used in authentication. The format depends on the `api.key.location` configuration. If location is `HEADER`, use the HTTP header name (for example, `X-API-KEY`). If location is `QUERY`, use the query parameter name (for example, `api_key`, `app_id`). The default value `X-API-KEY` is commonly used for header-based authentication.
   - **API key value**: The API key for an endpoint that requires API key-based authentication.

   **SSL**
   - **SSL enabled**: Controls whether to enforce TLSv1.3 for HTTPS connections. If `false`, the connector uses the JVM default TLS configuration (typically TLSv1.2). If `true`, the connector enforces TLSv1.3. Note that, even when disabled, HTTPS connections still use TLS. This setting only controls TLS version enforcement.
   - **SSL protocol**: The protocol to use for SSL connections.

   **Key Store**
   - **Upload key store**: The keystore that contains the client certificate and private key. Supported formats are `JKS` or `PKCS12`. File system paths are not supported.
   - **Keystore password**: The store password for the keystore file.
   - **Key password**: Enter the password for the private key in the key store file.

   **Trust Store**
   - **Upload trust store**: The truststore that contains the server CA certificate(s). Supported formats are `JKS` or `PKCS12`. File system paths are not supported.
   - **Trust store password**: Enter the trust store password containing a server CA certificate.

   **HTTP Proxy**
   - **Configure HTTP proxy**: Whether to route connector requests through an HTTP proxy. Enable this to set the proxy host, port, and optional credentials. This is a cloud-only setting used to control the visibility of the HTTP proxy settings.
   - **Proxy host**: The host name or IP address of the HTTP proxy used to route connector requests to the HTTP endpoint.
   - **Proxy port**: The port number on which the HTTP proxy is listening.
   - **Proxy username**: The username for authenticating with the HTTP proxy, if the proxy requires authentication.
   - **Proxy password**: The password for authenticating with the HTTP proxy, if the proxy requires authentication.

   **Host verification**
   - **Enable host verification**: Whether to enable SSL host verification, which validates that the server’s certificate matches the requested hostname.
2. Click **Authenticate**. Follow the authentication steps. If successful,
   you should see a message similar to “Authenticated successfully”.

### Paths

1. Select one or more endpoint paths for connector requests. You can
   select up to 15 paths. Add any resource IDs or sub-resource IDs as
   needed for the API endpoint path. The connector supports `GET`,
   `POST`, `PUT`, and `PATCH` operations.
2. Click **Continue**.

### Configuration

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

- **Input Kafka record value format**: Select the **Input Kafka record value** format (data coming from the
  Kafka topic): AVRO, BYTES, JSON, JSON_SR (JSON Schema), or PROTOBUF. 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 Schema, or Protobuf).
  Note that to consume STRING
  data, select schemaless JSON.

**API-1 | Topic**

- **Topics for the API**: The topic(s) to associate with this API.

**API-1 | Request configuration**

- **HTTP Request Parameters**: HTTP parameters to be added to each request. Parameter names and values should be separated by `=`. Distinct parameters should be separated by `&`.
- **HTTP Request Body**: The custom payload that will be sent to the destination instead of the record. The value can be templated with key, topic and any other record key (for example: `search_after: ${key}`) where `${key}` will be substituted with the key obtained from the record.
- **HTTP Path Parameters**: HTTP path parameters to be added to the request. Parameter names and values should be separated by `:`. Distinct parameters should be separated by `|`. Parameter values can be templated with different template values like `${key}`, `${topic}`, or other field references from Kafka record.
- **Headers**: HTTP headers to be included in each request. Header names and values should be separated by `:`. Distinct headers should be separated by `|`. For example: `From:abcxyz@confluent.io|Content-Length:348`. The UI splits the entered key/value pairs into individual rows for editing.
- **Sensitive headers**: Sensitive HTTP headers to include in each request. Sensitive header names and values should be separated by `:`. Distinct headers should be separated by `|`. For example: `From:abcxyz@confluent.io|Content-Length:348`. If a key is present in both regular and sensitive headers, the value in sensitive headers takes priority. This is a **CLI-only feature**.

**API-1 | Settings**

- **Behavior for null valued records**: Specifies how to handle records that have a non-null key and a null value
  (Kafka tombstone records). Valid options are `IGNORE`, `DELETE`, and `FAIL`.
  The default setting is `IGNORE`.

**Data decryption**

- Enable **Client-Side Field Level Encryption** for
  data decryption. Specify a **Service Account** to
  access the Schema Registry and associated encryption rules or keys with that schema. Select the connector behavior
  (`ERROR` or `NONE`) on data decryption failure. If set to `ERROR`, the connector fails and writes the encrypted data
  in the DLQ. If set to `NONE`, the connector writes the encrypted data in the target system without decryption.
  For more information on CSFLE or CSPE setup, see [Manage encryption for connectors](csfle.md#connect-csfle).

1. (Optional) Configure the following advanced configurations:

   ### **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).

   **Additional Configs**
   - **Value Converter Schemas Enable**: Includes schema within each of the serialized values. Input messages must contain `schema` and `payload` fields and must not contain additional fields. For plain `JSON` data, set this to `false`. Applies to the `JSON` converter.
   - **Value Converter Replace Null With Default**: Specifies whether to replace fields that have a default value and that are null to the default value. When set to `true`, the connector uses the default value; otherwise, it uses `null`. Applies to the `JSON` converter.
   - **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 to configure the connector’s error handling behavior.

     #### WARNING
     Use this property with caution for sink connectors, as it can lead to data loss. If you set this property to `all`, the connector does not fail on errant records, but logs them (and sends to DLQ for sink connectors) and continues processing. If you set this property to `none`, the connector task fails on errant records.
   - **Key Converter Schema ID Deserializer**: Sets the class name of the schema ID deserializer for keys. The deserializer reads schema IDs from message headers.
   - **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 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 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 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 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.
   - **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`.
   - **Value Converter Ignore Default For Nullables**: When set to `true`, this property ensures that the corresponding record in Kafka is `null`, instead of showing the default column value. Applies to the `AVRO`, `PROTOBUF`, and `JSON_SR` converters.
   - **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`.

   **Advanced configs**
   - **Error record format**: Dictates the content of records produced to the error topic.
   - **Reporter Result Topic Name**: The name of the topic to produce records to after successfully processing a sink record. Defaults to ‘success-${connector}’ if not set. You can provide `${connector}` in the value to use it as a placeholder for the logical cluster ID.
   - **Reporter Error Topic Name**: The name of the topic to produce records to after each unsuccessful record sink attempt. Defaults to ‘error-${connector}’ if not set. You can provide `${connector}` in the value to use it as a placeholder for the logical cluster ID.
   - **Dead Letter Queue 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.
   - **Behavior On Errors**: The error handling behavior setting for HTTP request error responses.

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

   **API-1 | Settings**
   - **Request Body Format**: The format of the request body. Valid options are JSON or String. The default value is JSON. Note that if `input.data.format` is `STRING`, you should also set `api1.request.body.format` to `STRING`.
   - **Batch key pattern**: Pattern used to build the key for a given batch. ${key} and ${topic} can be used to include message attributes here
   - **Batch max size**: The number of records accumulated in a batch before the HTTP API is invoked. Note that Basic and Standard Clusters may experience throughput limitations, even with a higher batch size.
   - **Batch prefix**: Prefix added to record batches. This is applied once at the beginning of the batch of records
   - **Batch suffix**: Suffix added to record batches. This is applied once at the end of the batch of records
   - **Batch separator**: Separator for records in a batch. This configuration can be set via CLI only.
   - **Batch json as array**: Whether to bundle JSON records into an array. This property only applies when `request.body.format` is set to `json`. Setting it to `false` disables batching for JSON request bodies. To disable batching for other formats, set `max.batch.size` to `1`.
   - **Regular expression patterns**: Regular expression patterns used for replacements in the message sent to the HTTP service. Multiple regular expression patterns can be specified, but must be separated by `regex.separator`. This configuration can be set via CLI only.
   - **Regular expression replacements**: Regex replacements to use with the patterns in `regex.patterns`.  Multiple replacements can be specified, but must be separated by `regex.separator`. `${key}` and `${topic}` can be used here. This configuration can be set via CLI only.
   - **Regular expression separator**: Separator character used in `regex.patterns` and `regex.replacements` property. This configuration can be set via CLI only.
   - **Allow GET Request Body**: Allow Request Body in case of GET call. This configuration can be set via CLI only.
   - **Report only status code to success topic**: Whether to report only the status code to the success topic. If the API response payload is huge, it is recommended to set this to true, for better throughput. Please note that this is a **CLI only feature**.
   - **HTTP Path Parameters Separator**: The character that separates multiple distinct path parameters within `http.path.parameters`. This configuration can be set using the CLI only.
   - **Upsert HTTP method**: The HTTP method to use for upserting. Valid options are `POST` or `NONE`. Setting the value to `NONE` disables upsert. The connector does not support batching for upsert operations.
   - **Upsert condition on field value**: When this property is set, the connector performs an upsert if the record value has a matching `jsonPath=expected_value`. This property must not be set if `api1.upsert.method` is `NONE`.
   - **Upsert API path**: The API path the connector uses when performing an UPSERT. This is mandatory when `api1.upsert.method` is set to `POST`. This property must not be set if `api1.upsert.method` is `NONE`.
   - **Forward Kafka Headers**: Whether to forward Kafka record headers as HTTP headers. When set to false, Kafka headers are ignored for HTTP request construction and batching grouping.
   - **Connect timeout (milliseconds)**: The time in milliseconds to wait for a connection to be established
   - **Request timeout (milliseconds)**: The time in milliseconds to wait for a request response from the server
   - **HTTP Response Compression**: Whether to enable GZip compression on HTTP responses. Valid options are `true` and `false`. Default is `true`. The HTTP server must support compression for this setting to work.
   - **Maximum Retries**: The maximum number of times to retry on errors before failing the task.
   - **Retry Backoff Policy**: The backoff policy to use in terms of retry - CONSTANT_VALUE or EXPONENTIAL_WITH_JITTER
   - **Retry Backoff (ms)**: The initial duration in milliseconds to wait following an error before a retry attempt is made. Subsequent backoff attempts can be a constant value or exponential with jitter (can be configured using api\*.retry.backoff.policy parameter). Jitter adds randomness to the exponential backoff algorithm to prevent synchronized retries.
   - **Retry HTTP Status Codes**: Comma-separated list of HTTP status codes or range of codes to retry on. Ranges are specified with start and optional end code. Range boundaries are inclusive. For instance, 400- includes all codes greater than or equal to 400. 400-500 includes codes from 400 to 500, including 500. Multiple ranges and single codes can be specified together to achieve fine-grained control over retry behavior. For example, 404,408,500- will retry on 404 NOT FOUND, 408 REQUEST TIMEOUT, and all 5xx error codes. Note that some status codes will always be retried, such as unauthorized, timeouts and too many requests.
   - **HTTP Request Headers Separator**: The character that separates multiple distinct headers within `http.request.headers`. This configuration can be set via CLI only.
   - **HTTP Request Parameters Separator**: The character that separates multiple distinct request parameters within `http.request.parameters`. This configuration can be set via CLI only.

   **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-http-sink-v2-config-properties) for all property
   values and definitions.
2. (Optional) If you wish to test the API, click **Test**. A **Test
   API** dialog box should appear. Follow the prompts to check for a
   valid API response. If the test is successful, you should see an HTTP
   `200 OK` response. Click **Close**. For more help with using the
   **Test API**, see the [Test API](#cc-http-sink-v2-test-api) section.

   #### NOTE
   The **Test API** invokes the target endpoint and could alter data
   in the end system.
3. Click **Continue**.

### Transforms

Use SMTs to make simple and
lightweight modifications to message values, keys, and headers. Add
Predicates to conditionally apply a transformation only to records
that match certain conditions. Click **Add SMT** to add an SMT. For
details, see the [Single Message Transformations](single-message-transforms.md#cc-single-message-transforms) documentation.

### Sizing

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. Note that the number of tasks should be greater
   than or equal to the number of HTTP APIs you configured.
2. Click **Continue**.

### Review and launch

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

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


#### Step 5: Check for records

Verify that records are being produced at 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.

Note that Dead Letter Queue (DLQ), success, and error topics are automatically
created for the connector. For more details, see [View Connector Dead Letter Queue Errors in Confluent Cloud](dead-letter-queue.md#ccloud-dlq-topics).

### Using the Confluent CLI

To set up and run the connector using the Confluent CLI, complete the
following steps, but ensure you have met all [prerequisites](#cc-http-sink-v2-prereqs).

#### 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-http-sink-v2-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
{
  "topics": "topic_0",
  "schema.context.name": "default",
  "value.subject.name.strategy": "TopicNameStrategy",
  "input.data.format": "AVRO",
  "connector.class": "HttpSinkV2",
  "name": "HttpSinkV2Connector_0",
  "kafka.auth.mode": "KAFKA_API_KEY",
  "kafka.api.key": "<my-kafka-api-key>",
  "kafka.api.secret": "<my-kafka-api-secret>",
  "max.poll.interval.ms": "300000",
  "max.poll.records": "500",
  "tasks.max": "1",
  "http.api.base.url": "http://example.com/absenceManagement/v1",
  "auth.type": "NONE",
  "https.ssl.enabled": "false",
  "https.host.verifier.enabled": "true",
  "behavior.on.error": "FAIL",
  "apis.num": "1",
  "api1.http.request.method": "POST",
  "api1.http.connect.timeout.ms": "30000",
  "api1.http.request.timeout.ms": "30000",
  "api1.behavior.on.null.values": "IGNORE",
  "api1.max.retries": "5",
  "api1.request.body.format": "JSON",
  "api1.retry.backoff.policy": "EXPONENTIAL_WITH_JITTER",
  "api1.max.batch.size": "1",
  "api1.retry.backoff.ms": "3000",
  "api1.retry.on.status.codes": "400-",
  "api1.http.request.headers.separator": "|",
  "api1.http.request.parameters.separator": "&",
  "api1.batch.separator": ",",
  "api1.batch.json.as.array": "false",
  "api1.http.path.parameters.separator": "|",
  "api1.test.api": "false",
  "api1.allow.get.request.body": "false",
}
```

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 **STRING**, **AVRO**, **JSON_SR**, **PROTOBUF**,
  **JSON**, or **BYTES**. You must have Confluent Cloud Schema Registry configured if using a
  schema-based message format (for example, Avro, JSON Schema, or Protobuf).
  When using **STRING**, we recommend setting `request.body.format` to `STRING`.
* `"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
  ```

* `"request.method"`: Enter an HTTP API Request Method: `PUT`, `POST`,
  `GET`, `PATCH`, or `DELETE`. Defaults to `POST`.
* `"topics"`: Enter the topic name or a comma-separated list of topic names.
* `"api1.http.api.path"`: Configure the API path with template parameters like `${key}` and `${topic}`.

  For example: If your API path is `/users/${key}/orders`, and the Kafka record key is `user123`, the final URL becomes `/users/user123/orders`.
* `"api1.http.path.parameters"`: Configure HTTP path parameters with template variables. Parameter names and values should be separated by `:`. Distinct parameters should be separated by `|`. Parameter values can be templated with different template values like `${key}`, `${topic}`, or other field references from the Kafka record.

  For example:

  Configuration: `"api1.http.path.parameters": "userId:${key}|orderId:${orderId}|my_topic:${topic}"`

  **Before substitution**:
  \* URL template: `/users/{userId}/orders/{orderId}?topic={my_topic}`
  \* Kafka record key: `user123`
  \* orderId field value: `order456`
  \* Topic name: `orders-topic`

  **After substitution**:
  \* Final URL: `/users/user123/orders/order456?topic=orders-topic`

#### NOTE
To enable CSFLE or CSPE for data encryption, specify the following properties:

* `csfle.enabled`: Flag to indicate whether the connector honors CSFLE or CSPE rules.
* `sr.service.account.id`: A Service Account to access the Schema Registry and associated encryption rules or keys with that schema.
* `csfle.onFailure`: Configures the connector behavior (`ERROR` or `NONE`) on data decryption failure.
  If set to `ERROR`, the connector fails and writes the encrypted data
  in the DLQ. If set to `NONE`, the connector writes the encrypted data in the target system without decryption.

When using CSFLE or CSPE with connectors that route failed messages to a Dead Letter Queue (DLQ),
be aware that data sent to the DLQ is written in unencrypted plaintext. This poses
a significant security risk as sensitive data that should be encrypted may be exposed in the DLQ.

Do not use DLQ with CSFLE or CSPE in the current version. If you need error handling for
CSFLE- or CSPE-enabled data, use alternative approaches such as:

* Setting the connector behavior to `ERROR` to throw exceptions instead of routing to DLQ
* Implementing custom error handling in your applications
* Using `NONE` to pass encrypted data through without decryption

For more information on CSFLE or CSPE setup, see [Manage encryption for connectors](csfle.md#connect-csfle).

**SMTs**: For details about adding SMTs using the Confluent CLI, see
the [Single Message Transformations](single-message-transforms.md#cc-single-message-transforms)
documentation. For all property values and descriptions, see
[Configuration Properties](#cc-http-sink-v2-config-properties).

#### 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 http-sink-v2-config.json
```

Example output:

```none
Created connector HttpSinkV2Connector_0 lcc-do6vzd
```

#### Step 5: 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   | HttpSinkV2Connector_0         | RUNNING | sink |       |
```

#### Step 6: 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.

Note that Dead Letter Queue (DLQ), success, and error topics are automatically
created for the connector. For more details, see [View Connector Dead Letter Queue Errors in Confluent Cloud](dead-letter-queue.md#ccloud-dlq-topics).

## Error records and status codes

The connector may report `status_code = -1` in error records when no HTTP
response code is available. This usually happens with client-side or transport
failures that occur before the server can respond. For example, DNS failures,
connection refused errors, connect/read timeouts, or TLS handshake errors.

When the server responds with a non-2xx status, the connector reports the actual HTTP code, for example, 400 or 500.

<a id="cc-http-sink-v2-path-parameters-example"></a>

## Using path parameters

You can use path parameters to dynamically inject values from your Kafka records into the API endpoint path.
This example shows how to map a field from a JSON record to a placeholder in the URL.

1. **Input record:** The connector processes a JSON record containing a `phone` field:
   ```json
   {
     "name": "John",
     "phone": "12349087"
   }
   ```
2. **Connector Configuration:** Define the placeholder within the `api1.http.api.path`, then map that placeholder
   to the record field using `api1.http.path.parameters`:
   ```json
   {
     "api1.http.api.path": "/restapi/assets/{phone}/layer/content",
     "api1.http.path.parameters": "phone:${phone}"
   }
   ```
3. **Resulting API path:** The connector resolves the variable and sends the request to the following path:
   ```text
   /restapi/assets/12349087/layer/content
   ```

#### NOTE
If you are configuring the connector via Confluent CLI, you might need to escape the dollar sign
(`\${phone}`) to prevent the shell from interpreting it as an environment variable.

<a id="cc-http-sink-v2-test-api"></a>

## Test API

Use the **Test API** functionality to test the API with a sample record and view
the logs directly in the Confluent Cloud user interface.

#### IMPORTANT
- This feature is only available for publicly accessible endpoints.
- Invoking the **Test API** on an API may change data on the end system,
  depending on the API’s behavior.

When using this feature with the HTTP Sink V2 connector, add your details to the
following fields:

- **${topic}**: Topic that the API is expected to consume from. Note that the
  connector will not actually read anything from the topic, and the topic name
  configured here will be used wherever you have configured the `${topic}`
  template variable.
- **Test message**: This message should reflect the data present in the Kafka
  topic. You must configure the expected Kafka key, headers, and values as
  applicable depending on the `value` of `request.body.format`.

  By default, `request.body.format` is set to JSON format. In this case, `value` should be a
  valid JSON string escaped and enclosed as a string, as shown below:
  ```json
  {
    "key": "key1",
    "headers": [
      {
        "header1": "h1"
      },
      {
        "header2": "h2"
      }
    ],
    "value": "{\"msg\": \"hello world\"}"
  }
  ```

  When `request.body.format` set to string format, you can use `value` as any string, as shown below:
  ```json
  {
    "key": "key1",
    "headers": [
      {
        "header1": "h1"
      },
      {
        "header2": "h2"
      }
    ],
    "value": "hello world"
  }
  ```

<a id="cc-http-sink-v2-legacy-v2-migration"></a>

## Moving from V1 to V2

Confluent recommends upgrading from version 1 to version 2 of this connector to take advantage of the
latest features, including support for [CSFLE](csfle.md#connect-csfle) and configuration through an
[OpenAPI/Swagger specification file](#cc-http-sink-v2-connection).

Use the following steps to migrate to version 2 connector. Implement and validate any
connector changes in a pre-production environment before promoting to
production.

1. Pause the V1 connector.
2. Get the [offset](https://docs.confluent.io/cloud/current/ccloud/get-connectv-1-connector-offsets/) for the V1 connector.
3. Create the V2 connector using the offset from the previous step.
   ```none
   confluent connect cluster create [flags]
   ```

   For example:

   Create a configuration file with connector configs and offsets.
   ```none
   {
     "name": "(connector-name)",
     "config": {
         ... // connector specific configuration
     },
     "offsets": [
         {
             "partition": {
         ... // connector specific configuration
             },
             "offset": {
         ... // connector specific configuration
             }
         }
     ]
   }
   ```

   Create a V2 connector in the current or specified Kafka cluster context.
   ```none
   confluent connect cluster create --config-file config.json
   ```
4. Verify the migration and confirm that the connector is running successfully with the V1 payloads.
5. [Delete](https://docs.confluent.io/cloud/current/ccloud/delete-connectv-1-connector/) the V1 connector.

For more information on offsets, see [Manage Offsets for Fully Managed Connectors in Confluent Cloud](offsets.md#connect-custom-offsets).

#### NOTE
Optionally, you can use [HTTP V2 Sink migration
tool](https://github.com/confluentinc/confluent-connector-migration-tool/tree/master/http-v2-sink)
to migrate to the V2 connector.

<a id="cc-http-sink-v2-config-properties"></a>

## Configuration Properties

Use the following configuration properties with the fully managed HTTP V2 Sink
connector.

### Add connector details

`name`
: Sets a name for your connector.
  <br/>
  * Type: string
  * Valid Values: A string at most 64 characters long
  * 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

### 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, JSON, BYTES or STRING. 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
  * Default: JSON
  * Importance: high

### How should we connect to your data?

`use.open.api.spec`
: Whether to drive the connector configuration from an OpenAPI (OAS 3.0 or higher) specification.
  <br/>
  * Type: boolean
  * Default: true
  * Importance: high

`open.api.spec.format`
: How you want to provide the OpenAPI specification — either a URL endpoint or an uploaded YAML/JSON file.
  <br/>
  * Type: string
  * Default: URL
  * Importance: high

`open.api.spec.url`
: URL endpoint that hosts the OpenAPI specification (OAS 3.0 or higher) in YAML or JSON format.
  <br/>
  * Type: string
  * Importance: high

`open.api.spec.file`
: Uploaded OpenAPI specification (OAS 3.0 or higher) in YAML or JSON format. Maximum file size 3 MB.
  <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

### 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

### Authentication

`secret.manager.enabled`
: Fetch sensitive configuration values from a secret manager.
  <br/>
  * Type: boolean
  * Default: false
  * Importance: high

`https.host.verifier.enabled`
: Whether to enable SSL host verification, which validates that the server’s certificate matches the requested hostname.
  <br/>
  * Type: boolean
  * Default: true
  * Importance: medium

### Service connection

`http.api.base.url`
: The HTTP API Base URL. For example: `http://example.com/absenceManagement/v1`. When an OpenAPI spec is provided, this is dynamically populated from the parsed spec’s base URLs.
  <br/>
  * Type: string
  * Importance: high

`auth.type`
: Authentication type of the endpoint. Valid values are `NONE`, `BASIC`, `OAUTH2` (Client Credentials grant type only), `BEARER`, `API_KEY`. When an OpenAPI spec is provided, this list is narrowed to the auth schemes declared by the spec.
  <br/>
  * Type: string
  * Default: NONE
  * Importance: high

`bearer.token`
: The bearer authentication token to be used with an endpoint requiring bearer token based authentication.
  <br/>
  * Type: password
  * Importance: medium

`oauth2.client.id`
: The client id used when fetching the OAuth2 token.
  <br/>
  * Type: string
  * Importance: medium

`oauth2.client.secret`
: The client secret used when fetching the OAuth2 token.
  <br/>
  * Type: password
  * Importance: medium

`connection.user`
: The username to be used with an endpoint requiring basic authentication.
  <br/>
  * Type: string
  * Importance: medium

`oauth2.client.auth.mode`
: Specifies how to encode `client_id` and `client_secret` in the OAuth2 authorization request. If set to `header`, the credentials are encoded as an `'Authorization: Basic <base-64 encoded client_id:client_secret>'` HTTP header. If set to `url`, then `client_id` and `client_secret` are sent as URL encoded parameters.
  <br/>
  * Type: string
  * Default: header
  * Importance: medium

`oauth2.client.scope`
: The scope parameter sent to the service when fetching the OAuth2 token.
  <br/>
  * Type: string
  * Default: any
  * Importance: medium

`connection.password`
: The password to be used with an endpoint requiring basic authentication.
  <br/>
  * Type: password
  * Importance: medium

`oauth2.token.property`
: The name of the property containing the OAuth2 token returned by the OAuth2 token URL (defaults to access_token).
  <br/>
  * Type: string
  * Default: access_token
  * Importance: medium

`oauth2.client.header.separator`
: Separator character used in OAuth2 Client Headers.
  <br/>
  * Type: string
  * Default: |
  * Importance: low

`oauth2.token.url`
: The URL to be used for fetching the OAuth2 token. Client Credentials is the only supported grant type.
  <br/>
  * Type: string
  * Importance: medium

`oauth2.client.headers`
: HTTP headers to be included in the OAuth2 client endpoint. Individual headers should be separated by `|`.
  <br/>
  * Type: password
  * Importance: low

`https.ssl.enabled`
: Controls whether to enforce TLSv1.3 for HTTPS connections. If false, the connector uses the JVM default TLS configuration (typically TLSv1.2). If true, TLSv1.3 is enforced. Note that, even when disabled, HTTPS connections still use TLS. This setting only controls TLS version enforcement.
  <br/>
  * Type: boolean
  * Default: false
  * Importance: medium

`https.ssl.keystorefile`
: The keystore that contains the client certificate and private key. Supported formats are JKS or PKCS12. File system paths are not supported.
  <br/>
  * Type: password
  * Default: [hidden]
  * Importance: low

`https.ssl.keystore.password`
: The store password for the key store file.
  <br/>
  * Type: password
  * Importance: high

`https.ssl.key.password`
: The password for the private key in the key store file.
  <br/>
  * Type: password
  * Importance: high

`https.ssl.truststorefile`
: The truststore that contains the server CA certificate(s). Supported formats are JKS or PKCS12. File system paths are not supported.
  <br/>
  * Type: password
  * Default: [hidden]
  * Importance: high

`https.ssl.truststore.password`
: The trust store password containing a server CA certificate.
  <br/>
  * Type: password
  * Importance: high

`https.ssl.protocol`
: The protocol to use for SSL connections
  <br/>
  * Type: string
  * Default: TLSv1.3
  * Importance: medium

`api.key.location`
: Specifies where the API key is included in the HTTP request. Choose `HEADER` to send the API key as an HTTP header (for example, `X-API-KEY: your-api-key`), or `QUERY` to include it as a query parameter in the URL (for example, `?api_key=your-api-key`). The default is `HEADER` which is the most common and secure approach.
  <br/>
  * Type: string
  * Default: HEADER
  * Importance: medium

`api.key.name`
: The identifier for the API key used in authentication. The format depends on the `api.key.location` configuration. If location is `HEADER`, use the HTTP header name (for example, `X-API-KEY`). If location is `QUERY`, use the query parameter name (for example, `api_key`, `app_id`). The default value `X-API-KEY` is commonly used for header-based authentication.
  <br/>
  * Type: string
  * Default: X-API-KEY
  * Importance: medium

`api.key.value`
: The API key to be used with an endpoint that requires API key-based authentication
  <br/>
  * Type: password
  * Importance: medium

`http.proxy.host`
: The host name or IP address of the HTTP proxy used to route connector requests to the HTTP endpoint.
  <br/>
  * Type: string
  * Importance: medium

`http.proxy.port`
: The port number on which the HTTP proxy is listening.
  <br/>
  * Type: int
  * Valid Values: [0,…,65535]
  * Importance: medium

`http.proxy.user`
: The username for authenticating with the HTTP proxy, if the proxy requires authentication.
  <br/>
  * Type: string
  * Importance: medium

`http.proxy.password`
: The password for authenticating with the HTTP proxy, if the proxy requires authentication.
  <br/>
  * Type: password
  * Importance: medium

`http.proxy.enabled`
: Whether to route connector requests through an HTTP proxy. Enable this to configure the proxy host, port, and optional credentials. This is a cloud-only setting used to control the visibility of the HTTP proxy settings.
  <br/>
  * Type: boolean
  * Default: false
  * Importance: medium

### Secret manager configuration

`secret.manager`
: Select the secret manager to use for retrieving sensitive data.
  <br/>
  * Type: string
  * Importance: high

`secret.manager.provider.integration.id`
: Select an existing provider integration that has access to your secret manager.
  <br/>
  * Type: string
  * Importance: high

`secret.manager.managed.configs`
: Select the configurations to fetch their values from the secret manager.
  <br/>
  * Type: list
  * Importance: high

### APIs

`apis.num`
: The number of http(s) APIs to configure. This value should be less than or equal to 15.
  <br/>
  * Type: int
  * Default: 1
  * Importance: high

### Additional Configs

`consumer.override.auto.offset.reset`
: Defines the behavior of the consumer when there is no committed position (which occurs when the group is first initialized) or when an offset is out of range. You can choose either to reset the position to the “earliest” offset (the default) or the “latest” offset. You can also select “none” if you would rather set the initial offset yourself and you are willing to handle out of range errors manually. More details: [https://docs.confluent.io/platform/current/installation/configuration/consumer-configs.html#auto-offset-reset](https://docs.confluent.io/platform/current/installation/configuration/consumer-configs.html#auto-offset-reset)
  <br/>
  * Type: string
  * Importance: low

`consumer.override.isolation.level`
: Controls how to read messages written transactionally. If set to read_committed, consumer.poll() will only return transactional messages which have been committed. If set to read_uncommitted (the default), consumer.poll() will return all messages, even transactional messages which have been aborted. Non-transactional messages will be returned unconditionally in either mode.  More details: [https://docs.confluent.io/platform/current/installation/configuration/consumer-configs.html#isolation-level](https://docs.confluent.io/platform/current/installation/configuration/consumer-configs.html#isolation-level)
  <br/>
  * Type: string
  * Importance: low

`header.converter`
: The converter class for the headers. This is used to serialize and deserialize the headers of the messages.
  <br/>
  * Type: string
  * Importance: low

`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.allow.optional.map.keys`
: Allow optional string map key when converting from Connect Schema to Avro Schema. Applicable for Avro Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.auto.register.schemas`
: Specify if the Serializer should attempt to register the Schema.
  <br/>
  * Type: boolean
  * 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.enhanced.avro.schema.support`
: Enable enhanced schema support to preserve package information and Enums. Applicable for Avro Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.enhanced.protobuf.schema.support`
: Enable enhanced schema support to preserve package information. Applicable for Protobuf Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.flatten.unions`
: Whether to flatten unions (oneofs). Applicable for Protobuf Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.generate.index.for.unions`
: Whether to generate an index suffix for unions. Applicable for Protobuf Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.generate.struct.for.nulls`
: Whether to generate a struct variable for null values. Applicable for Protobuf Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.int.for.enums`
: Whether to represent enums as integers. Applicable for Protobuf Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.latest.compatibility.strict`
: Verify latest subject version is backward compatible when use.latest.version is true.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.object.additional.properties`
: Whether to allow additional properties for object schemas. Applicable for JSON_SR Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.optional.for.nullables`
: Whether nullable fields should be specified with an optional label. Applicable for Protobuf Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.optional.for.proto2`
: Whether proto2 optionals are supported. Applicable for Protobuf Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.scrub.invalid.names`
: Whether to scrub invalid names by replacing invalid characters with valid characters. Applicable for Avro and Protobuf Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.use.latest.version`
: Use latest version of schema in subject for serialization when auto.register.schemas is false.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.use.optional.for.nonrequired`
: Whether to set non-required properties to be optional. Applicable for JSON_SR 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

`value.converter.wrapper.for.nullables`
: Whether nullable fields should use primitive wrapper messages. Applicable for Protobuf Converters.
  <br/>
  * Type: boolean
  * Importance: low

`value.converter.wrapper.for.raw.primitives`
: Whether a wrapper message should be interpreted as a raw primitive at root level. Applicable for Protobuf Converters.
  <br/>
  * Type: boolean
  * 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.flatten.singleton.unions`
: Whether to flatten singleton unions. Applicable for Avro and JSON_SR Converters.
  <br/>
  * Type: boolean
  * Default: false
  * Importance: low

`value.converter.ignore.default.for.nullables`
: When set to true, this property ensures that the corresponding record in Kafka is NULL, instead of showing the default column value. Applicable for AVRO,PROTOBUF and JSON_SR Converters.
  <br/>
  * Type: boolean
  * Default: false
  * 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.replace.null.with.default`
: Whether to replace fields that have a default value and that are null to the default value. When set to true, the default value is used, otherwise null is used. Applicable for JSON Converter.
  <br/>
  * Type: boolean
  * Default: true
  * Importance: low

`value.converter.schemas.enable`
: Include schemas within each of the serialized values. Input messages must contain schema and payload fields and may not contain additional fields. For plain JSON data, set this to false. Applicable for JSON Converter.
  <br/>
  * Type: boolean
  * Default: false
  * 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

`json.decimal.format`
: Specify the Request Body JSON 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 Connect DECIMAL logical type values in JSON Request Body as a number representing the decimal value. Applicable when request.body.format is json.
  <br/>
  * Type: string
  * Default: BASE64
  * Importance: medium

### Advanced configs

`behavior.on.error`
: Error handling behavior setting for handling error response from HTTP requests.
  <br/>
  * Type: string
  * Default: FAIL
  * Importance: low

`report.errors.as`
: Dictates the content of records produced to the error topic. If set to `Error string` the value would be a human readable string describing the failure. The value will include some or all of the following information if available: http response code, reason phrase, submitted payload, url, response content, exception and error message. If set to http_response, the value would be the plain response content for the request which failed to write the record. In both modes, any information about the failure will also be included in the error records headers.
  <br/>
  * Type: string
  * Default: Error string
  * Importance: low

`reporter.result.topic.name`
: The name of the topic to produce records to after successfully processing a sink record. Defaults to ‘success-${connector}’ if not set. You can provide `${connector}` in the value to use it as a placeholder for the logical cluster ID.
  <br/>
  * Type: string
  * Default: success-${connector}
  * Importance: low

`reporter.error.topic.name`
: The name of the topic to produce records to after each unsuccessful record sink attempt. Defaults to ‘error-${connector}’ if not set. You can provide `${connector}` in the value to use it as a placeholder for the logical cluster ID.
  <br/>
  * Type: string
  * Default: error-${connector}
  * Importance: low

`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

### API-1 | Topic

`api1.topics`
: List of topics for this API
  <br/>
  * Type: list
  * Default: “”
  * Importance: high

### API-1 | Path

`api1.http.api.path`
: The HTTP API path together with the `http.api.base.url` will form the complete HTTP(S) URL. This path can be templated with offset information. For example: `/resource1/${offset}` where `${offset}` will be substituted with the offset generated from the previous request’s response (or if it’s the first request, from `http.initial.offset`). When an OpenAPI spec is provided, this is populated from the parsed spec.
  <br/>
  * Type: string
  * Importance: high

`api1.http.request.method`
: The HTTP method to use. This supports `POST`, `PUT`, `PATCH`, `GET` and `DELETE`. If `DELETE` is selected, the body is omitted when making the API call. In addition, if the `api1.http.api.path` doesn’t have `${key}` or `${topic}` placeholders, `/${key}` is appended to the API path. When an OpenAPI spec is provided, this is populated from the parsed spec.
  <br/>
  * Type: string
  * Default: POST
  * Importance: high

### API-1 | Request configuration

`api1.http.request.parameters`
: HTTP parameters to be added to each request. Parameter names and values should be separated by `=`. Distinct parameters should be separated by `&`.
  <br/>
  * Type: string
  * Importance: medium

`api1.http.request.headers`
: HTTP headers to be included in each request. Header names and values should be separated by `:`. Distinct headers should be separated by `|`. For example: `From:abcxyz@confluent.io|Content-Length:348`. The UI splits the entered key/value pairs into individual rows for editing.
  <br/>
  * Type: string
  * Importance: medium

`api1.http.request.sensitive.headers`
: Sensitive HTTP headers to include in each request. Sensitive header names and values should be separated by `:`. Distinct headers should be separated by `|`. For example: `From:abcxyz@confluent.io|Content-Length:348`. If a key is present in both regular and sensitive headers, the value in sensitive headers takes priority. This is a **CLI-only feature**.
  <br/>
  * Type: password
  * Importance: medium

`api1.http.request.body`
: The custom payload that will be send to the destination instead of record. The value can be templated with key, topic and any other record key (for example: `search_after: ${key}`) where `${key}` will be substituted with the key obtained from the record.
  <br/>
  * Type: string
  * Importance: medium

`api1.http.path.parameters`
: HTTP path parameters to be added to the request. Parameter names and values should be separated by `:`. Distinct parameters should be separated by `|`. Parameter values can be templated with different template values like `${key}`, `${topic}`, or other field references from Kafka record.
  <br/>
  * Type: string
  * Importance: medium

### API-1 | Settings

`api1.http.connect.timeout.ms`
: The time in milliseconds to wait for a connection to be established
  <br/>
  * Type: int
  * Default: 30000 (30 seconds)
  * Valid Values: [1,…,600000]
  * Importance: medium

`api1.http.request.timeout.ms`
: The time in milliseconds to wait for a request response from the server
  <br/>
  * Type: int
  * Default: 30000 (30 seconds)
  * Valid Values: [1,…,600000]
  * Importance: medium

`api1.behavior.on.null.values`
: How to handle records with a non-null key and a null value (i.e. Kafka tombstone records). Valid options are `IGNORE`, `DELETE` and `FAIL`
  <br/>
  * Type: string
  * Default: IGNORE
  * Importance: low

`api1.request.body.format`
: The format of the request body. Valid options are JSON or String. The default value is JSON. Note that if `input.data.format` is `STRING`, you should also set `api1.request.body.format` to `STRING`.
  <br/>
  * Type: string
  * Default: JSON
  * Importance: medium

`api1.http.response.compression.enabled`
: Specify whether to enable GZip compression on HTTP responses. Valid options are `true` (default) and `false`. The HTTP server must support compression for this setting to work.
  <br/>
  * Type: boolean
  * Default: true
  * Importance: low

`api1.batch.key.pattern`
: Pattern used to build the key for a given batch. ${key} and ${topic} can be used to include message attributes here
  <br/>
  * Type: string
  * Importance: high

`api1.max.retries`
: The maximum number of times to retry on errors before failing the task. Must be between 1 and 5000
  <br/>
  * Type: int
  * Default: 5
  * Importance: medium

`api1.max.batch.size`
: The number of records accumulated in a batch before the HTTP API is invoked. Note that Basic and Standard Clusters may experience throughput limitations, even with a higher batch size.
  <br/>
  * Type: int
  * Default: 1
  * Importance: high

`api1.retry.backoff.policy`
: The backoff policy to use in terms of retry - CONSTANT_VALUE or EXPONENTIAL_WITH_JITTER
  <br/>
  * Type: string
  * Default: EXPONENTIAL_WITH_JITTER
  * Importance: medium

`api1.batch.prefix`
: Prefix added to record batches. This is applied once at the beginning of the batch of records
  <br/>
  * Type: string
  * Importance: high

`api1.retry.backoff.ms`
: The initial duration in milliseconds to wait following an error before a retry attempt is made. Subsequent backoff attempts can be a constant value or exponential with jitter (can be configured using api\*.retry.backoff.policy parameter). Jitter adds randomness to the exponential backoff algorithm to prevent synchronized retries.
  <br/>
  * Type: int
  * Default: 3000 (3 seconds)
  * Valid Values: [20,…,100000]
  * Importance: medium

`api1.batch.suffix`
: Suffix added to record batches. This is applied once at the end of the batch of records
  <br/>
  * Type: string
  * Importance: high

`api1.retry.on.status.codes`
: Comma-separated list of HTTP status codes or range of codes to retry on. Ranges are specified with start and optional end code. Range boundaries are inclusive. For instance, 400- includes all codes greater than or equal to 400. 400-500 includes codes from 400 to 500, including 500. Multiple ranges and single codes can be specified together to achieve fine-grained control over retry behavior. For example, 404,408,500- will retry on 404 NOT FOUND, 408 REQUEST TIMEOUT, and all 5xx error codes. Note that some status codes will always be retried, such as unauthorized, timeouts and too many requests.
  <br/>
  * Type: string
  * Default: 400-
  * Importance: medium

`api1.batch.separator`
: Separator for records in a batch.
  <br/>
  * Type: string
  * Default: ,
  * Importance: high

`api1.http.request.headers.separator`
: The character that separates multiple distinct headers within `http.request.headers`.
  <br/>
  * Type: string
  * Default: |
  * Importance: medium

`api1.batch.json.as.array`
: Whether or not to use an array to bundle json records. Only used when request.body.format is set to json. This can be disabled only when max.batch.size is set to 1.
  <br/>
  * Type: boolean
  * Default: false
  * Importance: high

`api1.http.request.parameters.separator`
: The character that separates multiple distinct request parameters within `http.request.parameters`.
  <br/>
  * Type: string
  * Default: &
  * Importance: medium

`api1.regex.patterns`
: Regular expression patterns used for replacements in the message sent to the HTTP service. Multiple regular expression patterns can be specified, but must be separated by `regex.separator`.
  <br/>
  * Type: string
  * Importance: medium

`api1.regex.replacements`
: Regex replacements to use with the patterns in `regex.patterns`.  Multiple replacements can be specified, but must be separated by `regex.separator`. `${key}`, `${topic}`, `${partition}`, and `${kafka_offset}` can be used here.
  <br/>
  * Type: string
  * Importance: medium

`api1.regex.separator`
: Separator character used in `regex.patterns` and `regex.replacements` property.
  <br/>
  * Type: string
  * Importance: medium

`api1.allow.get.request.body`
: Allow Request Body in case of GET call.
  <br/>
  * Type: boolean
  * Default: false
  * Importance: medium

`api1.report.only.status.code.to.success.topic`
: Whether to report only the status code to the success topic. If the API response payload is huge, it is recommended to set this to true, for better throughput.
  <br/>
  * Type: boolean
  * Default: false
  * Importance: medium

`api1.http.path.parameters.separator`
: The character that separates multiple distinct path parameters within `http.path.parameters`.
  <br/>
  * Type: string
  * Default: |
  * Importance: medium

`api1.upsert.method`
: The HTTP method to use for upserting. Valid options are `POST` or `NONE`. Setting the value to `NONE` disables upsert. The connector does not support batching for upsert operations.
  <br/>
  * Type: string
  * Default: NONE
  * Valid Values: NONE, POST
  * Importance: medium

`api1.upsert.on.field.value`
: When this property is set, the connector performs an upsert if the record value has a matching `jsonPath=expected_value`. This property must not be set if `api1.upsert.method` is `NONE`.
  <br/>
  * Type: string
  * Default: “”
  * Importance: medium

`api1.upsert.api.path`
: The API path the connector uses when performing an UPSERT. This is mandatory when `api1.upsert.method` is set to `POST`. This property must not be set if `api1.upsert.method` is `NONE`.
  <br/>
  * Type: string
  * Default: “”
  * Importance: medium

`api1.forward.kafka.headers`
: Whether to forward Kafka record headers as HTTP headers. When set to false, Kafka headers are ignored for HTTP request construction and batching grouping.
  <br/>
  * Type: boolean
  * Default: true
  * Importance: medium

### Auto-restart policy

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

<a id="cc-http-sink-v2-faq"></a>

## Frequently asked questions

Find answers to frequently asked questions about the HTTP Sink V2 connector for Confluent Cloud.

### Deployment model and product fit

#### Can I run HTTP Sink V2 on my own Kafka Connect cluster (self-managed)?

No. HTTP Sink V2 is available only as a fully managed connector on Confluent Cloud. It cannot be downloaded for
self-managed environments.

### Networking and reachability

#### Why do I see `http.api.base.url: Could not connect to the configured host:port`?

This error indicates the connector cannot reach the target URL from the Confluent Cloud workers. Common causes include:

* **Networking Mismatch:** If the cluster is `PRIVATE_LINK` or `PCC`, outbound traffic is not enabled by default.
* **Firewall Restrictions:** Confluent egress IP ranges or PrivateLink/VPC routes are not allowlisted in your upstream gateway or firewall.

**Checklist:**

1. **Check network type:** Is your cluster `PUBLIC` or `PRIVATE_LINK`?
2. **Verify PrivateLink:** Ensure the VPC path from Confluent to your endpoint is correctly configured.
3. **Allowlist IPs:** Confirm the Confluent egress IPs (or VPC CIDRs) are allowlisted at your API perimeter.
4. **Port check:** Ensure port `443` (or your custom port) is open.

#### Which IPs or CIDRs do I need to allowlist for HTTP Sink V2?

Data egress originates from Confluent-managed infrastructure.

* Use the documented egress IP address ranges for your specific region and cloud provider.
* For Azure Private Link, users often allowlist specific region CIDRs (for example, `westeurope-1` and `westeurope-2`).
* If the CLI returns only `global` prefixes, those are valid but the documentation table remains the source of truth.

#### Does the connector reuse HTTP connections, or does it open a new connection for every request?

The connector reuses an existing HTTP or HTTPS connection to the
target endpoint whenever the server allows it. Connection reuse
depends on the target server’s behavior:

* If the target server sends a `Connection: close` header (or otherwise
  closes the TCP connection) after every response, the connector cannot reuse
  that connection. It must open a new TCP connection, and, for HTTPS
  endpoints, perform a fresh TLS handshake, for every following request.
* Frequent new outbound connections increase the rate at which source ports
  are allocated and released on the Confluent Cloud networking layer. For
  connectors that generate requests at a high rate, this can contribute to
  Source Network Address Translation (SNAT) port exhaustion, which can
  appear as intermittent connection failures or increased latency.

**Recommendation:** If you control the target API, configure it to support
HTTP keep-alive, also known as persistent connections, instead of closing
the connection after each response. This reduces the number of new
connections and TLS handshakes the connector must perform, and lowers the
risk of SNAT port exhaustion under sustained use.

### Authentication, tokens and 401s

#### Which OAuth2 flows are supported? Can I use username/password grants?

* **Supported:** OAuth2 Client Credentials flow (`client_id` + `client_secret`). The connector obtains a bearer token and sends it as `Authorization: Bearer <token>`.

#### Can this connector use API key authentication?

Yes. Use `auth.type=API_KEY`. This connector issues requests using the headers as shown below:

```json
{
  "auth.type": "API_KEY",
  "api.key.name": "Authorization",
  "api.key.value": "GenieKey <your-api-key>"
}
```

#### NOTE
Use the Confluent CLI or REST API to use `API_KEY` authentication type.

#### Does the connector refresh the OAuth2 token on a `403 (Forbidden)` response?

No. The connector refreshes the OAuth2 token only when it receives an HTTP `401 (Unauthorized)` response. A
`403 (Forbidden)` response is treated as an authorization failure (for example, insufficient scope or
permissions) rather than an expired-token signal, so the token is not refreshed and the request is retried, if
configured, using the same token. If your endpoint returns `403` for expired or invalid tokens instead of
`401`, the connector cannot detect this and will not refresh the token automatically.

#### Curl works but the connector gets `401 (“Unauthorized”)`. Why?

There are three main causes:

- **Wrong HTTP method (POST vs PUT/DELETE):**
  The connector may default to `POST`. If the API requires `PUT`, you must explicitly override it:
  ```json
  "api1.http.request.method": "PUT"
  ```
- **Authentication header scheme mismatch (Bearer vs vendor-specific):**
  The `BEARER` authentication type sends `Authorization: Bearer <token>`. If your vendor (for example, Dynatrace) expects
  `Api-Token <token>`, use `NONE` and a custom header:
  ```json
  "auth.type": "NONE",
  "api1.http.request.headers": "Authorization: Api-Token <token>|Content-Type: application/json"
  ```
- **OAuth2 flow mismatch:**
  V2 supports OAuth2 Client Credentials. Resource Owner Password Authentication is not supported. If your system expects Authorization Code or Resource Owner Password,
  you must obtain the token externally and inject it as a static header.

#### Our OAuth2 provider does not allow a scope parameter. How do we suppress it?

If your identity provider (IdP) returns a `scope parameter not supported` error:

* **Using the REST API or CLI:** Set `"oauth2.client.scope": ""` to omit the parameter.
* **Cloud UI Workaround:** Enter a single space in the UI to prevent it from defaulting to `any`.

### HTTP status codes, retries, and error topics

#### Why do I see `Max Retries exhausted for operation` and a failed task?

This generic message indicates that retriable operations (like 500 errors) never succeeded after the configured attempts.

**Solution:** Correlate connector logs with the **Reporter error topic** (`error-<lcc-id>`) to find the specific HTTP code and response body.
Common causes include persistent `4xx/5xx` errors or DNS/TLS handshake failures.

### SMTs, offsets, and lag semantics

#### Why are some SMTs rejected as `invalid transforms`?

Allowed SMTs are enforced per organization for fully managed connectors. HTTP Sink V2 has specific SMT limitations.
Contact [Confluent Support](https://support.confluent.io/).

#### The connector is healthy but lag is always `1 per partition`. Is this normal?

Yes. This is a typical Kafka Connect behavior. The task pre-fetches the next record before committing the current offset.
Unless the lag is growing monotonically, `lag=1` is considered a healthy steady-state.

## Suggested Reading

The following blog post provides an introduction to the fully managed HTTP V2 Sink connector and a scenario walkthrough.

Blog post: [Optimize SaaS Integration with Fully Managed HTTP Connectors V2 for Confluent Cloud](https://www.confluent.io/blog/http-connectors-v2/)

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