feat(spec,service-automation): alipay-v3 joins the signed connector auth schemes, with response verification (ADR-0143 D2.3, slice 3 of #26710) (#28446)

domain:spec#4 · marchtian · session_017ihL2fi9zfJhUTubyJYb6V

🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_017ihL2fi9zfJhUTubyJYb6V

Fixes #26710

Clause-②: yes (widening)
Metadata-protocol: added
Skills-docs: updated here
(`skills/objectstack-automation/references/integration-recipes.md`;
`grep -rln "tencentcloud-tc3\|aliyun-acs3\|alipay" skills` hits that one
file)

## 维护者速读

- **改了什么**：连接器的 `signed` 签名认证新增第三个方案 `alipay-v3`。市场里对接支付宝开放平台 v3
的连接器，现在每个请求都会用应用私钥签名，每个响应都会用支付宝公钥验签；验签不过的响应直接让调用失败，内容不会进入流程。
- **为什么改**：#26710 的最后一片（S1 阿里云、S2 腾讯云已合并）。支付宝 v3 是目前找到的、国内平台里唯一官方发布
OpenAPI 文档的，有了它，中国区市场的支付宝连接器才能以纯元数据声明出来。
- **风险与回滚**：只新增一个方案，已有的 `bearer` / `api-key` / `basic` / `oauth2` / 阿里云
/ 腾讯云实例一行不变；回滚即整 PR 回退。本 PR 含 ADR-0143 D2.3 的一条日期注记（向量规则第三分支、验签范围），所以是
Tier H，需要人工批准。
- **先看**：①
`packages/services/service-automation/src/request-signing/alipay-v3.ts`（签名与验签，`alipayV3ResponseMustVerify`
一行定验签范围）；② `docs/adr/0143-outbound-connector-auth-is-open-tier.md` 的两条
2026-10-31 注记；③
`packages/connectors/connector-openapi/src/alipay-v3-acceptance.test.ts`（验收）。
- **两分钟验证**：`pnpm --filter @objectstack/connector-openapi exec vitest
run src/alipay-v3-acceptance.test.ts`，预期 3
个用例全绿：签名请求被本地支付宝网关接受、篡改或未签名的响应让调用失败、私钥不出现在任何请求与描述里。
- **需要你做的**：批准 ADR-0143 的两条 2026-10-31 注记（Tier H 的人工批准），契约复审与落地由席位完成。

## What changes

`alipay-v3` joins the `signed` scheme enum (ADR-0143 Q4, condition 1),
with its signer, its response verifier and vectors two official SDKs
agree on. This is slice 3 of 3; S1 (#28273, `aliyun-acs3-hmac-sha256`)
and S2 (#28279, `tencentcloud-tc3-hmac-sha256`) are merged.

- **`@objectstack/spec`**: `ConnectorSigningSchemeSchema` gains
`alipay-v3`; the `signed` union gains
`ConnectorInstanceSignedAlipayV3AuthSchema`, `{ type: 'signed', scheme:
'alipay-v3', keyId, credentialRef, vendorPublicKeyRef }`. `keyId` is the
app id, `credentialRef` the application private key,
`vendorPublicKeyRef` (required) the Alipay public key. The S1 publish
refusals apply (inline key spellings by name, an authored `signature`,
`signed` on `provider: 'mcp'`), plus `appPrivateKey` by name and
`alipayPublicKey` pointed at `vendorPublicKeyRef`; `appId` is answered
with `keyId`. The unknown-scheme refusal lists all three schemes.
- **`@objectstack/service-automation`**: `request-signing/alipay-v3.ts`
signs every attempt `ALIPAY-SHA256withRSA` with a fresh nonce and
millisecond timestamp, and verifies responses with the Alipay public key
before any body is parsed. The signer registry takes `{ key,
vendorPublicKey? }` instead of the bare key; its switch stays
exhaustive, so a scheme without a signer does not compile. The host
resolves `vendorPublicKeyRef` through the same chain as `credentialRef`:
an unresolved public key degrades the instance naming that reference, a
key that is not RSA fails boot naming which reference (never the value),
and the credential door lists both references against the instance, so
setting or replacing either one re-materializes it.
- **Docs**: `content/docs/automation/connectors.mdx` documents the
scheme, its two references and the boot table rows. It also fixes one S2
sentence: Tencent's default `Content-Type` applies to a request "without
a content type", not "without a body" (the signer keys on the header, as
its own docblock says).
- **ADR-0143** (Tier H): one dated note under D2.3 (the third branch of
the vector rule, the response-verification rule) and one under
Acceptance (the local end-to-end test counts, per the ruling quoted
below).

### The response-verification rule: a seat call, named

The two official SDKs disagree on which responses carry a signature that
must verify. Java v3 3.1.89 verifies a 2xx unless its body is empty and
verifies an error response only when it is signed; Node `alipay-sdk`
4.14.0 verifies every response below 400, an empty body included, and
never verifies an error response. The seat chose the stricter rule in
each case:

- every response **below 400** must carry a valid signature, **an empty
body included**;
- a **signed** error response (400 and above) is verified;
- an **unsigned** error response passes through as the error it already
is.

The rule is one function, `alipayV3ResponseMustVerify`, so a different
ruling changes one line. The ADR note records it.

### Rulings this rests on (binding, quoted)

- Vectors, option B: the maintainer, 2026-10-31, 「其他同意」. The vectors
come from `com.alipay.sdk:alipay-sdk-java-v3:3.1.89.ALL` and
`alipay-sdk` 4.14.0 (Node) over one placeholder key that belongs to no
app; the two outputs are byte-identical; the generator is kept in
`packages/services/service-automation/test-vectors/alipay-v3/`.
- Acceptance: the maintainer, 2026-10-31, 「算」: the in-repo end-to-end
test against a local vendor-shaped server counts, and no live sandbox
call is owed. That is why this PR carries the closing line above.

### Flags for the contract review

- **PD#2 (no business logic in `packages/spec`).** Response verification
runs through `readConnectorResponse` and the per-attempt signing wrap in
`packages/spec/src/integration/connector-fetch-policy.ts`, which landed
with S1. This slice adds no logic there, but it is the first scheme
whose `verifyResponse` is non-empty, so it is the first that relies on
that runtime code living in the spec package.
- **ADR-0143 D4 (grant-bearing kinds resolve per dispatch).** D4 names
"a signer bound to its key for `signed`" as the per-dispatch answer. As
in S1 and S2, the signer is built at materialization, and the key's
fingerprint joins the instance signature, so a rotated key
re-materializes instead of being re-read per dispatch. This slice
extends the same binding to `vendorPublicKeyRef` (the credential-door
test pins the re-materialization on replace).
- **Tier H.** The ADR-0143 notes make this PR Tier H.

**Independent review: none run (quota); the PR waits for the seat's
contract-review hand-off.**

## Tests

- **Vectors** (`request-signing/alipay-v3.test.ts`): the POST (JSON
body) and GET (query, no body) `Authorization` headers and one response
signature, as both SDKs produced them, reproduced byte for byte; a wrong
key differs; tampered body, tampered nonce and missing signature on a
2xx refused; unsigned empty 2xx refused; signed error verified, unsigned
error passed; refusals never carry the body, the signature or a key;
fresh nonce and instant per attempt; bare-base64 and PEM keys read;
non-RSA keys refused without echo.
- **Host** (`connector-materialization.test.ts`,
`connector-credential-door.test.ts`): signer bound to both keys and
neither key in the provider context; public key unresolved degrades
naming it; a non-key public key fails boot without echo; the door lists
both references, and setting or replacing the public key
re-materializes.
- **Spec** (`connector-auth-signed.test.ts`,
`type-alias-convention.pin.test.ts`): the shape on `rest` and `openapi`,
the refusals above, `vendorPublicKeyRef` required on `alipay-v3` and
refused on the other schemes.
- **Acceptance** (`connector-openapi/src/alipay-v3-acceptance.test.ts`):
a real boot (LiteKernel, AutomationServicePlugin,
ConnectorOpenApiPlugin) with an `openapi` instance over the vendor's
`alipay.trade.query` operation, dispatched through a flow
`connector_action` to a local gateway stand-in that checks the request
signature and signs its answer; a tampered or unsigned answer fails the
dispatch and its body never reaches the flow; the private key appears in
no request and no connector descriptor.

## Acceptance notes

- Public-key mode only; Alipay's certificate mode (`app_cert_sn`) is not
implemented, and the docs say so.
- The placeholder RSA pair under `test-vectors/alipay-v3/` is named
`PLACEHOLDER-test-only-…` and belongs to no Alipay app.
- `skills/objectstack-automation/references/integration-recipes.md` is
corrected here (commits `10c6ddf7b3`, `1083e85431`; the seat amended the
claim surface on #26710): the `signed` scheme list now names
`alipay-v3`, and the "RSA-signing vendor … blocked on the
request-signing card" line now says only WeChat Pay has no scheme yet.
The earlier plan to carry this on #28226 did not hold: #28226 is closed
and never added the Alipay text. `skills/**` is a second Tier H surface
on a PR that is already Tier H.

## Verification

All readings below are on head `7497850ebb`, except the skills fix on
`1083e85431`: its six derived skills gates (`check-skills-token-ratchet`
and its self-test, `check:agent-test-spelling`,
`check:pm-skill-id-lint`, `check:skill-compatibility`,
`check:skill-frame-sync`) exit 0, `--ran` 116 of 116; the file stays
under its token ceiling (2235 of 2236). The rest of this section reads
(the branch after merging `origin/main` at `aaa5c1df8d`; the merge
regenerated `content/docs/references/index.mdx` and `check:generated` is
green on all 14 artifacts).

<details><summary>Gates: 110 derived, 110 run, all exit 0; `--ran` 0
NOT-MEASURED; `pnpm lint` exit 0</summary>

- `node scripts/pm/dispatch-gates.mjs --commands --repo
objectstack-ai/objectstack` derived 110 commands; each was run with its
exit code captured before any pipe. 109 exited 0 on the first run. `pnpm
check:type-check-debt` first exited 3 (PREREQUISITE NOT MET: its closure
build never got a turn on the shared verify lock), and exited 0 when
re-run inside the lock (0 ledger entries above their recorded number).
- `dispatch-gates --ran` over the `command :: exit code` record: 110
derived, 110 run, 0 NOT-MEASURED (derived from the recorded codes).
- `pnpm lint`: exit 0.
- `pnpm --filter @objectstack/spec check:generated`: all 14 generated
artifacts up to date.

</details>

<details><summary>Tests and typecheck</summary>

- `pnpm typecheck` for `@objectstack/spec`,
`@objectstack/service-automation`, `@objectstack/connector-openapi`,
`@objectstack/connector-rest`: exit 0.
- `@objectstack/service-automation`: 245 files, 3126 tests passed.
- `@objectstack/connector-openapi`: 8 files, 92 tests passed (includes
the acceptance test).
- `@objectstack/connector-rest`: 5 files, 43 tests passed.
- `@objectstack/spec` (`src/integration`, `src/shared`,
`src/type-alias-convention.pin.test.ts`): 50 files, 1170 tests passed.
The full spec suite is left to CI.

</details>

<details><summary>Ablations: each mutation landed on disk, went red, and
was restored to the HEAD blob</summary>

Run with `scripts/ablation-replace.mjs` (anchor hit 1 to 0, blob
changed, restore proven against the HEAD blob; `git status --porcelain`
empty afterwards). The subjects are reached through source (a relative
import, or the `@objectstack/service-automation` source alias in
`connector-openapi`'s vitest config), so no build is involved.

1. **Drop the response-signature check** (`verifyResponse` in
`alipay-v3.ts` made a no-op): `alipay-v3.test.ts` 4 red (tampered body /
nonce / missing signature on a 2xx; unsigned empty 2xx; signed error;
refusal text), and the acceptance test's case 2 (tampered or unsigned
answer fails the dispatch) red.
2. **Swap one byte of the POST vector** (`sign=F…` to `sign=G…` in the
pinned `Authorization`): 5 red, led by "reproduces the POST (JSON body)
request signature".
3. **Drop `alipay-v3` from the signer switch**
(`request-signing/index.ts`): `service-automation` typecheck exit 2,
`TS2322` naming the `alipay-v3` shape as not assignable to `never`.

</details>

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: objectstack-fleet[bot]

.changeset/26710-signed-connector-auth-alipay.md

@@ -0,0 +1,31 @@
+---
+'@objectstack/spec': minor
+'@objectstack/service-automation': minor
+---
+
+feat(spec): `alipay-v3` joins the `signed` connector-instance auth schemes, with response verification (ADR-0143 D2.3, #26710)
+
+Clause-②: yes (widening)
+Metadata-protocol: added
+
+<!-- adr-0087: not-required (no-migration-prescription) One member is added to the closed signing-scheme list and one shape to the `signed` union. The signer registry's third parameter changes from the key string to an object carrying the key and an optional vendor public key; that function is internal to the automation service and in no release yet (it ships with the pending `26710-signed-connector-auth-aliyun` changeset). Nothing an author wrote before is refused or re-shaped, so there is nothing for a migration to rewrite. -->
+
+A declarative connector instance can now declare Alipay's OpenAPI v3 signature as its signing scheme. Its responses are verified too. It joins the Alibaba Cloud and Tencent Cloud schemes.
+
+- **`@objectstack/spec`**
+  - `ConnectorSigningSchemeSchema` gains `alipay-v3`.
+  - The `signed` union gains its closed shape: `{ type: 'signed', scheme: 'alipay-v3', keyId, credentialRef, vendorPublicKeyRef }`.
+    - `keyId` is the app id.
+    - `credentialRef` names the application private key.
+    - `vendorPublicKeyRef` names the Alipay public key that every response is verified with. It is required.
+  - The same publish refusals apply as for the other schemes: inline key spellings by name, an authored `signature`, and `signed` on `provider: 'mcp'`. Also refused:
+    - `appPrivateKey`, by name;
+    - `alipayPublicKey`, which is answered with `vendorPublicKeyRef`.
+
+    `appId` is answered with `keyId`. An unknown scheme's refusal now lists all three schemes.
+- **`@objectstack/service-automation`**
+  - Every request is signed `ALIPAY-SHA256withRSA` with a fresh nonce and timestamp.
+  - Every response below status 400 must carry a valid Alipay signature, an empty body included. A signed error response is verified too. A response that fails either check fails the dispatch, and its body is never returned.
+  - The vendor public key resolves through the same chain as `credentialRef`. An instance whose public key is missing is degraded with that reference named. The credential door lists both references against the instance.
+  - A key that is not an RSA key fails boot, naming which reference, never the value.
+  - The keys never leave the host.

content/docs/automation/connectors.mdx

@@ -617,7 +617,9 @@ Some upstreams take no token at all: every request carries a signature over its
 own method, path, query, headers and body, computed with a key the caller never
 sends. The `signed` kind declares that (ADR-0143 D2.3). The metadata names the
 **scheme** and the public **key id**; the signing key itself is a
-`credentialRef`, resolved through the same chain as every other kind.
+`credentialRef`, resolved through the same chain as every other kind. A scheme
+whose vendor signs its responses also names the vendor's public key, as a
+second reference.
 
 ```ts
 // Alibaba Cloud OpenAPI, V3 signature (ACS3-HMAC-SHA256):
@@ -635,8 +637,22 @@ auth: {
   keyId: 'YourSecretId',                  // the SecretId: public, stays in metadata
   credentialRef: 'TENCENT_SECRET_KEY',
 }
+
+// Alipay OpenAPI v3 (ALIPAY-SHA256withRSA), responses verified:
+auth: {
+  type: 'signed',
+  scheme: 'alipay-v3',
+  keyId: '2021000000000000',              // the app id: public, stays in metadata
+  credentialRef: 'ALIPAY_APP_PRIVATE_KEY', // the application private key (RSA)
+  vendorPublicKeyRef: 'ALIPAY_PUBLIC_KEY', // the Alipay public key responses are verified with
+}
 ```
 
+Both of an `alipay-v3` instance's references are listed against it by the
+credential door, and setting or replacing either one re-materializes it. The
+keys are accepted as Alipay's console issues them (the bare base64 body) or as
+PEM.
+
 What the platform does with it:
 
 - **Every request is signed, each attempt fresh.** A retry is signed again with
@@ -648,7 +664,8 @@ What the platform does with it:
   (`external.connector` is refused with `422`): a driver cannot sign per
   request.
 - **Schemes that sign their responses are verified** before a result is
-  returned; a response that does not verify fails the dispatch.
+  returned; a response that does not verify fails the dispatch, and its body
+  never reaches the flow.
 - **`aliyun-acs3-hmac-sha256`** signs `host`, `content-type` and every
   `x-acs-*` header, and sets `x-acs-date`, `x-acs-signature-nonce`,
   `x-acs-content-sha256` and `Authorization`. The API's own action and version
@@ -659,9 +676,16 @@ What the platform does with it:
   the first label of the endpoint host (`cvm.tencentcloudapi.com`, or a
   regional `cvm.ap-guangzhou.tencentcloudapi.com`, is `cvm`), so point
   `baseUrl` at the product's own endpoint. `X-TC-Action`, `X-TC-Version` and
-  `X-TC-Region` are yours to send and are not signed. A request without a body
-  is sent with `Content-Type: application/x-www-form-urlencoded`, the type it
-  is signed with.
+  `X-TC-Region` are yours to send and are not signed. A request without a
+  content type is sent with `Content-Type: application/x-www-form-urlencoded`,
+  the type it is signed with.
+- **`alipay-v3`** signs the method, the path and query as sent and the body,
+  with a fresh nonce and millisecond timestamp, and sets `Authorization:
+  ALIPAY-SHA256withRSA app_id=…,nonce=…,timestamp=…,sign=…`. Every response
+  below status 400 must carry a valid `alipay-signature` (an empty body too),
+  checked against the key `vendorPublicKeyRef` names; an error response is
+  verified when it is signed, and an unsigned one fails as the error it is.
+  Public-key mode only: Alipay's certificate mode is not supported.
 
 What the publish door refuses:
 
@@ -670,9 +694,11 @@ What the publish door refuses:
   signer and its test vectors, so a scheme the server cannot run is never
   accepted.
 - **An inline key**: `secret`, `privateKey`, `secretKey` or `accessKeySecret`
-  is refused by name, pointing at `credentialRef`. The vendors' words for the
-  key id (`accessKeyId`, `secretId`) are answered with `keyId`. An authored `signature` is
-  refused too: it is computed for every request.
+  is refused by name, pointing at `credentialRef` (on `alipay-v3`,
+  `appPrivateKey` too, and `alipayPublicKey` points at `vendorPublicKeyRef`).
+  The vendors' words for the key id (`accessKeyId`, `secretId`, `appId`) are
+  answered with `keyId`. An authored `signature` is refused too: it is computed
+  for every request.
 - **`provider: 'mcp'`**, at `auth.type`: an MCP server is not signed per
   request. Declare `provider: 'rest'` or `provider: 'openapi'`.
 
@@ -736,7 +762,9 @@ retry):
 | An `authorization_code` instance nobody connected, or whose grant the vendor refused | **Not fatal**: the instance registers **degraded**, "not connected" or "reconnect required" — connect it (`POST …/connectors/:name/connection`), and it materializes without a restart |
 | The token endpoint is unreachable or answers `5xx` / `429` | **Not fatal**: the dispatch fails `CONNECTOR_UPSTREAM_UNAVAILABLE` and is retried on the existing backoff; the connection stays connected |
 | `auth` is `signed` on a provider that does not say it applies the request signer | **Hard boot error** naming the instance, the scheme and the provider: its calls would go out unsigned — declare it through `rest` or `openapi` |
-| `credentialRef` resolves to nothing | **Not fatal**: the instance registers **degraded**, naming the reference — set it (`PUT …/credential-refs/:ref`), and it materializes without a restart |
+| `credentialRef` (or a `signed` instance's `vendorPublicKeyRef`) resolves to nothing | **Not fatal**: the instance registers **degraded**, naming the reference — set it (`PUT …/credential-refs/:ref`), and it materializes without a restart |
+| A `signed` reference resolves to something that is not a key of the scheme's kind (an `alipay-v3` key that is not RSA) | **Hard boot error** naming the instance and which reference cannot sign or verify, never the value |
+| A response to an `alipay-v3` call is unsigned (below status 400) or its signature does not verify | The dispatch **fails** naming the instance and the status; the response's body is never returned |
 | The upstream refuses the credential (`401` / `403`) | **Not fatal**: the instance registers **degraded**. A stored credential is marked `rejected` and waits until it is set again (or a restart); an environment or vault credential is retried on the backoff |
 | Instance `name` collides with a plugin-registered connector | **Hard boot error** — there is no silent precedence between the two worlds |
 | stdio transport without host opt-in | **Hard boot error** with the `declarativeStdio` fix inline — a security rejection is never retried |

content/docs/references/index.mdx

@@ -1,7 +1,7 @@
 ---
 title: Protocol reference — every schema by module
 navTitle: Protocol Reference
-description: Every schema published by @objectstack/spec — 1576 schemas across 14 protocol modules
+description: Every schema published by @objectstack/spec — 1577 schemas across 14 protocol modules
 ---
 
 {/* ⚠️  AUTO-GENERATED — DO NOT EDIT. Run build-docs.ts to regenerate. Hand-written docs live in the module folders under content/docs/. */}
@@ -25,7 +25,7 @@ counts are sums of the rows they head. Regenerate with
 | [Automation Protocol](/docs/references/automation) | 15 | 77 | Flows and their nodes, approvals, ETL pipelines, webhooks, state machines, execution records. |
 | [Data Protocol](/docs/references/data) | 31 | 174 | Objects, fields, queries, filters, datasources and drivers — the ObjectQL layer. |
 | [Identity Protocol](/docs/references/identity) | 5 | 27 | Users and accounts, organizations, positions, SCIM provisioning. |
-| [Integration Protocol](/docs/references/integration) | 1 | 22 | The single connector protocol (ADR-0097) — catalog descriptors and provider-bound instances. |
+| [Integration Protocol](/docs/references/integration) | 1 | 23 | The single connector protocol (ADR-0097) — catalog descriptors and provider-bound instances. |
 | [Kernel Protocol](/docs/references/kernel) | 29 | 151 | Plugin lifecycle and manifests, capabilities and security, metadata loading, service registry. |
 | [Marketplace Protocol](/docs/references/marketplace) | 4 | 30 | The package & marketplace format — package identity and versions, listing, publish, review, search, install, template manifests. |
 | [QA Protocol](/docs/references/qa) | 1 | 8 | Declarative test suites — scenarios, steps, actions and assertions. |
@@ -34,7 +34,7 @@ counts are sums of the rows they head. Regenerate with
 | [Studio Protocol](/docs/references/studio) | 3 | 35 | Studio designer metadata — the authoring surfaces for the protocols above. |
 | [System Protocol](/docs/references/system) | 37 | 287 | The runtime environment — logging, jobs, cache, metrics, notifications, i18n and compliance. |
 | [UI Protocol](/docs/references/ui) | 16 | 175 | Apps, pages, views, dashboards, reports, actions and themes — the ObjectUI layer. |
-| **Total** | **204** | **1576** | 14 protocol modules |
+| **Total** | **204** | **1577** | 14 protocol modules |
 
 ---
 
@@ -192,13 +192,13 @@ Users and accounts, organizations, positions, SCIM provisioning.
 
 ## Integration Protocol
 
-**Source:** `packages/spec/src/integration/` · **Import:** `@objectstack/spec/integration` · **1 page, 22 schemas**
+**Source:** `packages/spec/src/integration/` · **Import:** `@objectstack/spec/integration` · **1 page, 23 schemas**
 
 The single connector protocol (ADR-0097) — catalog descriptors and provider-bound instances.
 
 | File | Schemas |
 | :--- | :--- |
-| [`connector.zod.ts`](/docs/references/integration/connector) | `Connector`, `ConnectorAction`, `ConnectorActionEffect`, `ConnectorAppCredentialVendor`, `ConnectorInstanceAPIKeyAuth`, `ConnectorInstanceAppCredentialAuth`, `ConnectorInstanceAuth`, `ConnectorInstanceBasicAuth`, `ConnectorInstanceBearerAuth`, `ConnectorInstanceNoAuth`, `ConnectorInstanceOAuth2Auth`, `ConnectorInstanceOAuth2AuthorizationCodeAuth`, `ConnectorInstanceOAuth2ClientCredentialsAuth`, `ConnectorInstanceSignedAliyunAcs3Auth`, `ConnectorInstanceSignedAuth`, `ConnectorInstanceSignedTencentCloudTc3Auth`, `ConnectorOAuth2Grant`, `ConnectorRetryStrategy`, `ConnectorSigningScheme`, `ConnectorType`, `DeclarativeConnectorEntry`, `RetryConfig` |
+| [`connector.zod.ts`](/docs/references/integration/connector) | `Connector`, `ConnectorAction`, `ConnectorActionEffect`, `ConnectorAppCredentialVendor`, `ConnectorInstanceAPIKeyAuth`, `ConnectorInstanceAppCredentialAuth`, `ConnectorInstanceAuth`, `ConnectorInstanceBasicAuth`, `ConnectorInstanceBearerAuth`, `ConnectorInstanceNoAuth`, `ConnectorInstanceOAuth2Auth`, `ConnectorInstanceOAuth2AuthorizationCodeAuth`, `ConnectorInstanceOAuth2ClientCredentialsAuth`, `ConnectorInstanceSignedAlipayV3Auth`, `ConnectorInstanceSignedAliyunAcs3Auth`, `ConnectorInstanceSignedAuth`, `ConnectorInstanceSignedTencentCloudTc3Auth`, `ConnectorOAuth2Grant`, `ConnectorRetryStrategy`, `ConnectorSigningScheme`, `ConnectorType`, `DeclarativeConnectorEntry`, `RetryConfig` |
 
 ---