Published at: 2026-10-12
Integration Approach Selection Guide
Learn the applicable boundaries and selection methods for prebuilt connectors, project connectors, and HTTP components.
Overview
Before an integration project enters platform configuration, you need to choose the right integration approach. The platform provides three approaches: prebuilt connectors, project connectors, and HTTP components. The core goal of selection is to prioritize reusing existing platform capabilities and reduce duplicate development.
Core Concepts
The positioning of the three approaches is as follows:
| Approach | Positioning |
|---|---|
| Prebuilt Connector | A connector already listed on the platform and ready to configure |
| Project Connector | A connector accumulated through the connector development tool for a project or high-frequency system |
| HTTP Component | A general component that directly calls the other system through an HTTP API |
General Principles
Integration projects should prioritize existing platform capabilities and minimize duplicate development.
The recommended selection order is:
Prioritize prebuilt connectors. When no prebuilt connector exists, check whether the system has a standard API and interface documentation. If it has a standard API with reuse value, prefer project connector development; if it has a standard API but low reuse value, use an HTTP component to call it directly. When no API is available, first drive customer-side API construction or re-evaluate the solution.
Integration Approach Selection Table
| Condition | Recommended approach | Description |
|---|---|---|
| The platform has a prebuilt connector that meets project requirements | Prebuilt Connector | Prioritize use to reduce development and adaptation costs |
| No prebuilt connector, but the external system has a standard API with reuse value | Project Connector | Use the connector development tool to accumulate connector capabilities |
| No prebuilt connector, but the external system has API documentation, and the project is highly customized or has low reuse value | HTTP Component | Call the other system’s API directly through the HTTP component |
| The external system has no API, no documentation, or an uncallable API | Not ready for configuration | Confirm the customer’s API capability or drive API construction first |
| The external system requires special protocols, complex authentication, or highly complex logic | Determined after technical evaluation | May require R&D support or a dedicated solution design |
The Three Approaches
Prebuilt Connector
Applies when the platform already has a listed connector, the customer’s system API is standard, and the project requirements fall within the connector’s supported scope.
Best for: standard SaaS systems, private-deployment systems with standard APIs, and mature platform connectors.
Project Connector
Applies when the platform has no prebuilt connector, but the external system has a standard API with complete documentation and future reuse value.
Best for: new systems, high-frequency systems, and API scenarios reusable across multiple projects.
HTTP Component
Applies when the platform has no prebuilt connector, the project API is highly customized, reuse value is unclear, but the other system already provides a callable HTTP API.
Best for: customer self-built systems, single-project APIs, lightweight APIs, and quick validation.
Cases Not Recommended for Direct Configuration
The following cases are not recommended for entering platform configuration directly:
- The external system has no open API
- The customer cannot provide API documentation
- The API response structure is unstable
- The authentication method is unclear
- The allowlist, network, and security boundaries are not confirmed
- The API call frequency, rate limits, and pagination rules are unclear
- A complex private protocol is required
- Large-scale historical data sync, but the API does not support batch or pagination
- The customer IT needs to develop the API first, but the responsibility and plan are not confirmed
Usage Notes
Do Not Expand the Platform Capability Boundary
Do not assume that all systems can be automatically connected, or that integration is possible without APIs. Likewise, do not assume that all connectors are mature, AI can complete integration projects automatically, complex logic needs no R&D support, or all historical data can be synced without risk.
Standard capabilities can be reused. Custom requirements must be evaluated against the customer’s API capabilities, business rules, and security requirements.
Prioritize Prebuilt Connectors
For mature connectors already available on the platform, new projects should prioritize delivery through the System Integration Platform. Current priorities include Kingdee Cloud, Feishu Bitable, and other connectors that are mature and have completed project validation.
A Standard API Is the Prerequisite for Project Delivery
Whether using a project connector or an HTTP component, the external system must have an API foundation. At minimum it should provide the API address, request method, authentication method, request parameters, response structure, error codes, field descriptions, and a test environment.
Design First, Then Configure for Complex Scenarios
For multi-system chaining, multi-branch logic, large-scale historical data, and Multi-Org multi-tenant scenarios, complete the integration flow design and technical evaluation before entering platform configuration. The same applies to strong security, high real-time requirements, multi-API transaction consistency, complex failure compensation, and unstable customer APIs.
Record All Pending Items Explicitly
Common pending items include whether the API exists, who provides the API, the authentication method, the allowlist, and field mapping. Also confirm the historical data scope, sync frequency, failure retry rules, exception notification recipients, manual compensation path, launch time, and operations responsibility.