Corsair (corsairdev/corsair): a self-hostable integration layer for agents and multi-tenant dashboards

The glue-code problem Corsair is aimed at

Any product that lets users connect their own accounts ends up writing the same code repeatedly. Each provider has its own token endpoint, its own refresh semantics, its own pagination style, and its own error shape. The README states the motivation plainly: "The more third-party APIs your agent touches, the more glue code you write." Corsair's answer is to put a single syntax in front of all of them and maintain the adapters behind it.

The audience follows from that. It is not a consumer app or a general workflow builder. It is for teams shipping an AI agent that has to act inside a user's existing tools, and for teams shipping a dashboard where each customer connects their own accounts. Both cases need the same thing: per-tenant credentials stored somewhere the team controls, and one calling convention that does not change when a provider is added.

The README also draws a line against MCP-only tooling. Its claim is that because Corsair is built on a REST API, the same integration layer serves agents, backend services, and customer dashboards, rather than only the agent runtime.

How the integration layer is put together

The repository is a pnpm workspace with turbo driving builds and tests. The root package.json is private and named @corsair/root; the build, dev, test and release scripts all filter on ./packages/* and ./adapters/*, which tells you the split: core packages on one side, provider adapters on the other. Adapters are the maintained part. If a provider changes its API, the change belongs in an adapter rather than in your application.

The top-level tree also contains explorer/, docs/, www/, demo/ and skills/, plus AGENTS.md and CLAUDE.md at the root. The demo directory holds a set of runnable entry points: demo/langchain/, demo/mastra/, demo/mcp/, demo/minimal/, demo/sdk/ and demo/testing/. Those names map onto the stated positioning. demo/mcp/ is the MCP path, demo/langchain/ and demo/mastra/ are agent frameworks, demo/sdk/ is direct use of the client, and demo/minimal/ is presumably the smallest end-to-end example.

Corsair's own README says it is "built on a REST API". That is the architectural bet: the integration surface is HTTP, not a framework-specific binding, so a dashboard written in one stack and an agent written in another can call the same endpoints. The README does not publish the endpoint list, the auth header format, or the response envelope, so the REST surface has to be read from the code or the docs site.

Self-hosting is the other half. The README contrasts Corsair with "closed integration platforms" that "keep your users' tokens and data on infrastructure you can't inspect or leave". Running it yourself means you hold the tokens. The README offers a hosted option called Hub for teams that would rather not run OAuth refresh and webhooks themselves, and states that data ownership is the same either way.

Installing Corsair and making a first call

Corsair is distributed as an npm package named corsair, and the repository is a pnpm workspace pinned to [email protected]. If you are working from the repository rather than the published package, install the workspace dependencies with pnpm, then build the packages and adapters. The build script uses turbo with filters, so it compiles ./packages/* and ./adapters/* together.

pnpm install
pnpm build

After that, the demo directory is the place to start. The README does not spell out install steps, so the entry points to read are demo/minimal/ for the smallest example and demo/sdk/ for the client itself. The repository also exposes a dev script that runs the same filtered set in watch mode, which is what you want while writing an adapter.

pnpm dev

The root package.json lists two generator scripts for new integrations, both run with Node's type stripping enabled. If you are adding a provider rather than consuming one, that is the supported path.

pnpm generate:plugin
pnpm generate:plugin-from-json

One process note from CONTRIBUTING.md: the README says to claim a new integration on the OSS Integrations page before starting, then open an issue for the API you want to add. That is a coordination step, not a technical one, but it matters if you plan to upstream your adapter rather than keep it private.

Where Corsair is the wrong choice

The most concrete limitation is documentation depth. The README is a positioning document. It explains why the project exists and how to contribute, but it does not document the REST endpoints, the token storage model, the refresh flow, or rollback behaviour. For a project whose entire value proposition is holding other people's OAuth credentials, that is a real gap: you cannot evaluate the security posture of the token handling from the README alone. You have to read the packages.

Release cadence is the second signal. The only release listed is v0.1.0, tagged on 2025-12-05. A 0.1 line means the API surface can move, and the root scripts include a canary publish path, which is consistent with a project still finding its shape. The last push to the default branch was on 2026-09-10, so work is happening, but a single published version is not the same as a stable contract.

The licence is the third thing to check. The repository metadata reports NOASSERTION for the licence, while the README states the project is licensed under Apache License, Version 2.0 and points at the LICENSE file. Those two do not agree on their face. Before you build a product on Corsair, open LICENSE and read it, because the answer changes what you can do with the code.

Finally, if your integration needs are narrow, Corsair is overhead. One provider, one internal service, no multi-tenant dashboard: write the client directly. The value here comes from breadth and from tenant isolation, and neither pays off at a single integration.

Corsair against calling provider SDKs yourself

The honest alternative is not another platform. It is doing it manually: install each provider's official SDK, or call its REST API directly, and write your own token store, refresh loop and retry logic. That path has real advantages. You get the provider's own types, its own error messages, and its own documentation, which is usually better than any abstraction layer's. There is no middle component to debug when a call fails.

The difference in approach is where the maintenance sits. With direct SDKs, every provider you add is a new dependency, a new auth pattern and a new set of edge cases in your codebase, and that cost recurs for each one. With Corsair, the README's claim is that you "connect once instead of rewriting plumbing for each new tool", and the adapters/ directory is where that plumbing lives. The trade is that you now depend on the adapter being correct and current, and on the project's release schedule rather than the provider's.

There is a middle option worth naming, because Corsair's own README names it: MCP-only integration tools. Those are fine if your only consumer is an agent. They stop being fine when the same integration has to serve a customer-facing dashboard, which is exactly the case the README uses to justify the REST foundation.

Maintenance, upgrades and what the licence question costs you

Operating Corsair means operating a service. In the self-hosted configuration you own the OAuth refresh loop and the webhook handling, and you own the storage that holds user tokens. The README frames that as the point, and it is, but it is also the operational load you are taking on. The hosted Hub option exists precisely to move that load off your team, at the cost of running on someone else's infrastructure.

Upgrades are a monorepo concern. The root package.json drives releases with turbo plus bumpp, publishing every workspace package together with --access public, and there is a separate canary tag path. Because packages and adapters version in lockstep, an adapter update and a core update arrive as one unit, which reduces version-skew bugs but also means you cannot pull a single provider fix in isolation. The build script filters on ./packages/* and ./adapters/*, so a full build is the whole workspace.

On licensing, treat the discrepancy as unresolved until you read the file. The README says Apache License, Version 2.0. The repository metadata says NOASSERTION, which is what GitHub reports when it cannot identify a licence from the files present. Apache 2.0 is permissive and includes an explicit patent grant, but that is a general property of the licence text, not a statement about this repository. Read LICENSE before you depend on the answer, and if you are redistributing Corsair inside a product, have someone qualified read it too.

What to verify before you commit

Start with the code that handles credentials. Find where tokens are stored and where refresh happens, because that is the part of Corsair you are trusting with your users' accounts and the part the README does not describe. If you plan to use Hub instead of self-hosting, the same question applies to someone else's infrastructure.

Next, confirm the REST surface. The README asserts the platform is REST-based but does not publish the endpoints. Read demo/sdk/ and demo/minimal/ to see the actual call shape, and check whether the response envelope and error model are stable enough to build on. Then check the adapter you need exists in adapters/ or on the OSS Integrations page. If it does not, you are either writing it or waiting for it.

Finally, decide how much you care about the 0.1 version line. If your integration layer is a small part of the product, an unstable API is survivable. If it is the product, pin the versions and read the release notes before each upgrade, because the project publishes packages together and a core change can move the adapters with it.

Editorial conclusion

Adopt Corsair if you are building an agent or a multi-tenant dashboard that has to touch several third-party APIs and you want to keep user tokens on infrastructure you control. Do not adopt it if you need a documented OAuth refresh story, a published adapter list, or a stable API surface today: the release history is a single v0.1.0 tag from 2025-12-05, and the README links to the website and Discord rather than documenting the runtime. Before writing code, read LICENSE to settle the licence question, run pnpm install and pnpm build to confirm the workspace compiles, and open demo/minimal to see the smallest working call.

Frequently asked questions

Official sources

1. corsairdev/corsair on GitHub
2. Issues
3. Project website
4. README
5. Releases