[AVAILABLE] as a library.
packages/connector-sdk.Connector responsibilities — and what a Connector must never do
A Connector validates a request, executes using an already-resolved credential, and returns a deterministic response. A Connector never evaluates policy, authorizes execution, interprets AI output, makes a business decision, or resolves a credential itself — credential resolution happens exclusively inside the Execution Gateway, before a Connector is ever called.Capabilities are namespaced verbs
ConnectorCapability is a plain string, validated eagerly by connectorCapabilities()
against namespace:verb (e.g. http:get, crm:read, payments:refund) — a malformed
capability throws at connector construction, not at execution time. By convention,
ExecutableContent.action is the capability string; this is what
execution-control’s DefaultConnectorPolicy already checks unchanged.
Registering a connector
registry implements execution-control’s ConnectorRegistry interface (get()), so it
plugs directly into ExecutionControlService exactly like InMemoryConnectorRegistry.
Testing your connector hermetically
UseMockConnector to test anything upstream of your connector (policy wiring, routing)
without a real target system:
script: { failWith: new Error("upstream unavailable") }.
connector.invocations records every ConnectorRequest the connector received, so tests
can assert exactly what was executed.
Version and health checks fail closed
SdkConnectorExecutor rejects execution — before invoking your connector — if:
- an
expectedVersionwas configured at registration and the connector’s ownmetadata.versiondoesn’t match (guards a rolling deployment that swapped connector builds underneath a pinned expectation), or metadata.health.status === "unavailable".
What every connector’s evidence looks like
Every execution produces aConnectorEvidence object — connector ID, version, capability,
a sanitized endpoint (credentials and query parameters stripped), the credential provider’s
ID, redacted request/response summaries, timestamps, and a hash computed by the existing
TrustRecordHasher — attached at ExecutionResult.metadata.connector. See
Execution Trust Record for how this reaches the Trust Record
without any change to its schema or hashing pipeline.