Corsair Integration Architecture

Overview

Corsair is an application-owned integration boundary for connecting provider APIs to dashboards, knowledge bases, workflows, and agents. Across the series, plugins preserve provider-specific contracts while one runtime carries credentials, tenant scope, local entity projections, webhooks, retries, and policy. The progression moves from API-versus-database choices through encrypted account lifecycles, multi-tenant routing, inbound events, and agent approval to practical architecture. This reduces duplicated integration plumbing, but it does not replace application authorization, key custody, freshness policy, idempotency, semantic retrieval, or provider-specific testing.

Learning outcomes

Corsair’s main leverage is one runtime for provider calls, local entities, credentials, events, and policy.
Use `.api` for provider mutations or current reads, and `.db` for synchronized local reads that may lag.
`withTenant()` carries account scope through calls, entities, hooks, approvals, and workflows, but the application must authenticate the caller.
Agents and webhooks still require endpoint policy, signature checks, idempotency, and freshness rules owned by the application.

Keywords

CorsairIntegrationsPluginsAPIsCredentialsOAuthTenantsWebhooksAgentsPermissions

Chapters

Corsair Integration Boundary

Separate provider authority from application-owned state

9 min · Separate provider authority from application-owned state

9 min

Corsair Plugin Contract

Typed bindings keep provider semantics visible

8 min · Typed bindings keep provider semantics visible

8 min

Corsair API and Local State

Choose live reads, projections, and refreshes deliberately

9 min · Choose live reads, projections, and refreshes deliberately

9 min

Corsair Credential Lifecycle

Separate tenant secrets, encryption, and recovery

10 min · Separate tenant secrets, encryption, and recovery

10 min

Corsair Provider Action Flow

Trace scope, keys, provider calls, and local state

8 min · Trace scope, keys, provider calls, and local state

8 min

Corsair Multi-Tenant Scoping

Carry identity through credentials, entities, and workflows

8 min · Carry identity through credentials, entities, and workflows

8 min

Corsair Webhook Delivery

Verify, route, reconcile, and react without false guarantees

9 min · Verify, route, reconcile, and react without false guarantees

9 min

Corsair Agent Tool Control

Discover operations, scope tenants, gate risky actions

10 min · Discover operations, scope tenants, gate risky actions

10 min

Corsair Connected App Design

Choose surfaces while preserving identity, state, and authority

10 min · Choose surfaces while preserving identity, state, and authority

10 min

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans

Ch.1-3 FreeCh.4-9 Premium

FAQ

What is Corsair’s main architectural role?

Corsair provides an application-owned runtime boundary for provider APIs, credentials, synchronized entities, events, and agent tools. It standardizes the shared lifecycle while leaving provider semantics and business authorization to the application and plugins.

When should an application use Corsair `.api` versus `.db`?

Use `.api` for provider mutations or a value that must be current; use `.db` for synchronized lists, searches, and detail reads. Refreshes can call `.api` and then reread `.db`, but local state may need polling or verification.

How does Corsair isolate multiple tenants?

Corsair isolates tenants by routing calls, credentials, entities, approvals, hooks, and workflows through a tenant-scoped client such as `withTenant()`. The application must derive and authorize that tenant from a trusted identity context rather than accept an unchecked caller-supplied ID.

Does Corsair make agents or webhooks trustworthy by itself?

No. Corsair supplies discovery, endpoint policy, signature verification, and reconciliation paths, but the application still owns caller authorization, tenant resolution, key custody, idempotency, and freshness decisions.