> ## Documentation Index > Fetch the complete documentation index at: https://help.dingtalk.io/llms.txt > Use this file to discover all available pages before exploring further. # HTTP Connector > Learn how to use YiDA Connector Factory to create a custom HTTP connector, including creating the connector, configuring the authentication type, and creating an execute action. Intended for users who need to connect DingTalk apps with other systems in a custom way. | **Feature** | **Free plan** | **Basic edition** | **Professional edition** | Dedicated edition | | -------------- | ------------- | ----------------- | ------------------------ | ----------------- | | HTTP Connector | 1 | 1 | Unlimited | Unlimited | If the official DingTalk connectors do not meet your needs but you urgently need to connect DingTalk apps, self-built systems, or third-party app systems, build a custom connector using YiDA Connector Factory. ## Step 1: Create a Connector Sign in to the [YiDA workbench](https://www.yidaapps.com/workPlatform) as an admin. Click **Platform management** in the upper-right corner to open the platform management page. In the left-side menu, click **Connector Factory**, click **Create connector**, and then select HTTP Connector. | **Authentication type** | **Description** | | ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | No authentication | No authentication means no verification information is required, and the API can be called directly. Typically used to access public APIs. | | Basic authentication | Basic authentication relies on the Authorization request header of an HTTP request. The header contains the credential the server uses to verify the identity of the user agent.
• **Format**: `Authorization: Basic `.
For example, add `Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l` to the header, which is the Base64-encoded account and password.
You only need to configure the prompt labels for the account and password so that users know what to enter when registering the authentication information.
For example:
• **username label**
• **password label** | | API key | Refers to the **APIKey** authentication method. The APIKey remains valid for a long period (keep it safe). The visitor creates a secret key in the target system, and developers can then use this credential to call public APIs that support this authentication type.
• **Parameter label**: shown as a prompt when configuring authentication information.
• **Parameter name**: the name of the apiKey required by the system.
• **Parameter location**: choose to attach the authentication information to the query parameter or the header, based on the requirements of the target system. | | Alibaba Cloud API Gateway | After the connector is created, add an authentication template. Once the App Code is entered in the template, you can call the corresponding Alibaba Cloud APIs.
For more information, see [Call an API by using App Code authentication](https://help.aliyun.com/document_detail/115437.html). | | DingTalk Open Platform authentication | After the connector is created, add an authentication template. Once `App Key` and `App Secret` are entered in the template, you can call DingTalk Open Platform APIs (including some YiDA APIs).
After the authentication template is added, YiDA automatically generates the authentication parameter `access_token` and adds it to the `x-acs-dingtalk-access-token` parameter in the `Header` during the request. You do not need to generate it again.
For more information, see DingTalk app development process. | | DingTalk Zero Trust Gateway | For information about how to use the DingTalk Zero Trust Gateway, see DingTalk Open Platform - Zero Trust Gateway authentication. | ## Step 2: Create an Execute Action On the Execute Action page, click **Create execute action**, and then configure the action as described below. | **Name** | **Description** | | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Basic information | Configure the basic information of the current execute action.
• **Unique identifier**: used to distinguish different actions.
• Action name: the name of the execute action.
• Action description: the description of the execute action. | | API request | Configure which API to call when the current execute action is triggered.
• **Request URL**: the API request link. The request domain is automatically filled with the connector's domain.
• **HTTP method**: GET, POST, DELETE, PUT, HEAD, OPTIONS, PATCH, and other methods are supported.
• **Query**: the request parameters, typically the parameters appended after the question mark `?` in the URL. Click the plus sign to add one.
• **Body**: for POST requests and similar cases, a body field may also be included. It supports parsing using request JSON.
• **Headers**: customize additional request headers here. Only static configuration is currently supported.
• **Path**: variables enclosed in curly braces in the URL, such as `{pathParam}`, where `pathParam` is the variable name.
**Note**: Request parameters support configuring system fields such as the sign-in user ID and organization ID. | | API response | Configure the expected response after the API is called successfully. Parsing using JSON is supported.
**Note**: If the API response is not a JSON object, it cannot be used directly in integration & automation. Parse it manually in a script node. | ## Step 3: Configure Authentication All custom connectors require a corresponding request authentication scheme, even for "**No authentication**". 1. Create an account For a configured connector, click Test. You are prompted to select an authentication account, and you can also create a new one at this point. 2. Enter the account display name, App Key, App Secret, and other information, and then click Confirm. ## Step 4: Test the Connector