Consumer integration setup

Use ContractSpec integrations without rewriting provider glue

The OSS monorepo ships runtime adapters, provider families, concrete implementations, and harnesses. Consumers should choose an ownership mode first, then bind providers through explicit capabilities instead of calling SDKs directly from app surfaces.

Reusable integration code map

Setup flow

• Define the integration capability and data contract before importing a provider SDK.
• Pick BYOK, managed, or hybrid runtime mode based on who owns secrets, credentials, tenant connection records, and operational support.
• Install only the provider package family needed by the app surface, then bind it through the runtime adapter.
• Route secrets through the provider interface; never serialize secret values into examples, telemetry, reports, or client state.
• Add a test harness or fake adapter before enabling a real external provider in production-like flows.
• Keep provider-specific redirects, webhooks, retries, and rate-limit handling behind the integration boundary.

Binding shape

Treat this as an architecture pattern, not a copy-paste API guarantee: pick the runtime mode, resolve secrets through the runtime, then create the provider adapter behind a capability such as billing.payments, knowledge.embeddings, or communication.messaging.

1import { createIntegrationRuntime } from "@lssm-tech/integration.runtime";
2import { createManagedRuntime } from "@lssm-tech/integration.runtime-managed";
3import { createPaymentsProvider } from "@lssm-tech/integration.provider-payments";
4
5const runtime = createIntegrationRuntime({
6  mode: "managed",
7  secrets: createManagedRuntime({ tenantId }).secrets,
8  telemetry: "redacted",
9});
10
11export const payments = createPaymentsProvider({
12  runtime,
13  capability: "billing.payments",
14  tenantConnectionId: "tenant_conn_payments_primary",
15});