Published at: 2026-10-12
Overview
Learn about connector application types, the creation workflow, and authorization methods.
Overview
The ShareCRM Integration Platform iPaaS is a low-code integration platform for software vendors. Developers configure a connector’s authorization, triggers, and actions through a visual interface, completing system integration without writing code. After a connector goes live, users can orchestrate business processes through the visual canvas on the integration platform to enable data exchange between systems.
Core Concepts
The core concepts of connector development include:
- Application type: Internal connectors (used within the enterprise) and public connectors (available to all users)
- Authorization method: The authentication mechanism used when a connector integrates with a third-party platform, such as OAuth 2.0
- Trigger: Defines the conditions under which a connector triggers a data flow
- Action: Defines the specific operation a connector performs after triggering
- Function mode: The code configuration mode used when the page UI cannot meet requirements
Application Types
Type | Description |
|---|---|
Internal connector | Used only within the enterprise; goes live in real time after creation without review |
Public connector | Available to all ShareCRM users; requires review and testing before going live |
Creating a Connector
After your organization passes R&D limited rollout, fill in real information on the Setup > System Integration Platform > Connector Development page to create a connector.
Authorization Methods
OAuth 2.0 Authorization
OAuth 2.0 authorization configuration requires the following steps:
- Configure authorization fields (optional; only added when extra parameters are needed before OAuth 2.0 login authorization)
- Copy the callback address: add the automatically generated integration platform authorization callback address to your app
- Configure authorization parameters: generally the Client Key and Client Secret
- Configure API parameters: parameters required by the authorization API, Access Token exchange and refresh parameters, and so on
- Test account authorization (simulate account authorization to test whether data can be retrieved successfully)
Unified developer creation generally only applies when serving as an integration platform ISV vendor. If the user has a custom app, choose user self-creation. The difference is that with unified developer creation, the authorized app reuses the same app information.
OAuth Authorization Types
The OAuth authorization type specifies the OAuth 2.0 authorization method used when a connector integrates with a third-party platform.
Authorization type | Description |
|---|---|
OAuth 2.0 (Authorization Code) | The user completes login authorization and then obtains an access token |
OAuth 2.0 (Client Credentials) | The system uses client credentials to obtain an access token directly, without user involvement |
OAuth 2.0 (PKCE) | Adds PKCE verification on top of the authorization code mode, for frontend or mobile scenarios |
Other Authorization Methods
Authorization option | Authorization mechanism |
|---|---|
OAuth2-AuthorizationCode | Three-step authorization flow: obtain authorization code → exchange for Access Token → auto-refresh with Refresh Token; supports automatic PKCE handling, for third-party platforms requiring user login authorization |
OAuth2-ClientCredentials | Machine-to-machine authorization without user interaction; the platform uses Client ID / Client Secret directly to obtain a Token and re-applies it when expired |
APIKey | Authenticates via an API Key; the Key can be injected into the Header or Query parameters, for simple authentication scenarios such as OpenAPI and Server API |
BasicAuth | HTTP Basic authentication; uses username + password to generate the Authorization Header for request authentication |
SessionAuth | First calls the login API to obtain a Session / Cookie, then carries the Session to access subsequent APIs; for traditional web systems or cookie-session APIs |
DigestAuth | HTTP Digest authentication; completes digest signature authentication based on the server challenge mechanism, for some legacy systems or APIs with specific security requirements |
CustomAuth | Custom authentication; implements arbitrary authentication logic through the platform function mode, covering custom signatures, ticket exchange, multi-step authentication, and hybrid authentication |
Field Description
Authorization Page Configuration Fields
If you configure form fields on the authorization API page, those fields become available in subsequent API configurations. Authorization form parameters and any parameters returned by the authorization API are wrapped into
auth_data.Expressions used by the integration platform must always carry the
path prefix, followed by the specific parameter path, for example path("['auth_data']['access_token']").Trigger / Action Page Form Fields
When configuring form parameters for ordinary Triggers and Actions, if the API needs authorization parameters, use
path("['auth_data']['xxxxxxx']") under the same constraint; if the API needs input parameters, use the input_data expression.Function Mode
If the page UI cannot meet requirements for any API, you can switch to code mode (function mode). See the function mode reference for details.