Skip to main content
Almost everything built on Corsair is one of four shapes, or a combination of them. Each shape uses the same setup and the same two namespaces. What changes is where the data flows.

Dashboard

Render synced data from your database, act on it with live API calls.

Agent

Hand an LLM the whole integration surface as tools and let it decide.

Knowledge base

Search everything you’ve synced and answer questions from it.

Workflow

An event in one service triggers actions in another.

​
The one contract

Every shape rests on the same rule. Each plugin exposes two namespaces:
Both follow the same path: corsair.<plugin>.[db|api].<group>.<method>(args). Every .api response is upserted into your database automatically, and webhooks update the same rows in place. That’s why .db is the default for reads. It isn’t a cache you maintain, it’s a table Corsair keeps current. See Database.
Everything else on this page is a variation on which side of that line your feature sits.

​
Picking a shape

The deciding question is who chooses the operation. If you know at build time which endpoint to call, it’s a dashboard, knowledge base, or workflow, all plain TypeScript. If the operation is only known at runtime from a human sentence, it’s an agent, and you expose tools over MCP instead of hardcoding calls.

​
Combining shapes

Most real apps are two or three of these. A GitHub review tool might list open PRs (dashboard), let you say “close #458 as a duplicate” (agent), and post to Slack when a PR is merged (workflow). When you combine them, they share one foundation. Build it once:

​
One corsair.ts

A single createCorsair call listing every plugin you need.

​
One handler route

The management and Hub delivery endpoint, mounted once.

​
One connection per tenant

A plugin connected for a tenant is available to every shape in the app. Do not create a second Corsair instance for the chat feature, and don’t connect the same plugin twice. The agent reads and writes the same corsair_entities rows the dashboard renders, which is what lets a chat command show up on the page immediately.
The shapes differ in reads, not in setup. If you’ve finished Quick Start, you already have everything all four need.

​
Shared setup

Every use case assumes this much is done:
1

​
Install and configure

createCorsair({ plugins, database, kek, hub }) in src/server/corsair.ts, with the five tables migrated. Full walkthrough in Quick Start.
2

​
Mount the handler

One route serves the management API and Hub delivery. Every framework is covered in Handlers.
3

​
Connect a tenant

Mint a link with corsair.manage.connect.createLink({ plugin, tenantId }) and send the user to it. See Connect.
Then scope your calls with withTenant() and start reading. Multi-tenant details are in Multi-tenancy.

​
What’s next

Quick Start

The shared foundation, in five steps.

Build with your agent

Point a coding agent at these docs and have it scaffold the app.

Plugins

Every integration, with its install id and endpoint reference.

Database

The five tables and how they stay fresh.