Your governed knowledge, available to your other AI tools.
A contract-first REST API, signed webhooks, and an MCP server you run yourself — with the same audience scopes enforced identically across all three. Author once in Cairn, serve your Claude, your Copilot, your Slack bot, your internal agents.
POST /v1/retrieval/query
Authorization: Bearer crn_k1_…
Content-Type: application/json
{
"query": "how do I add a teammate",
"top_k": 5,
"filters": { "audiences": ["customers"] }
}
→ 200 · ranked chunks with source ids,
guide refs and step anchors.
Internal chunks are absent, not filtered —
a key without the internal ability never
sees them.01 — Integration surfaces
Six ways in, all built on the same contract.
02 — Contract first
The spec is the source of truth, and the build enforces it.
Which means the documentation cannot quietly drift away from the API you are actually calling.
Read the API reference →The last mile: your knowledge, governed once, reachable from everywhere.
Most knowledge bases are a dead end — content goes in and only that vendor's chatbot can read it. The Cairn MCP server makes the same audience-scoped knowledge available to whatever else your company runs, with the scopes enforced identically rather than reimplemented. You run it — over stdio beside your MCP client, or as a Streamable HTTP endpoint on your own infrastructure. Cairn does not host one, and the npm release is coming soon.
Exposed tools
cairn_search_knowledgeHybrid search over guides, help-center articles, crawled pages and uploads, returning ranked chunks with their source title, URL and a guide or article reference.cairn_get_guideOne published guide: its title, description and steps in order.cairn_get_articleOne published help-center article: its metadata and body.04 — Widget and walkthrough
Under 120KB, and it runs on your customers’ pages — so we treat the budget as a contract.
One snippet, or a JS API if you want to drive it yourself. Identity is HMAC-signed from your backend so the agent knows what the visitor is entitled to see before it answers. The walkthrough runtime is a further chunk under 25KB, loaded only when a walkthrough actually starts.
- Widget bundle
- Under 120KB, static CDN delivery
- Walkthrough runtime
- Under 25KB, loaded on demand
- Identity
- HMAC-SHA256 signed server-side
- Mobile
- iOS, Android, Flutter and React Native SDKs — built, not yet published
Widget JS API
// identify the visitor — hmac signed by your backend
Cairn.user.set({
email: "sofia@northwind.test",
name: "Sofia Marsh",
hmac: "<hmac-sha256>"
});
// open help, already searching
Cairn.helpdesk.query("add a teammate");
// play a published guide as a walkthrough
Cairn.walkthrough.start("<guide-id>");
// react to what happened
Cairn.on("experience:completed", fn);
Cairn.on("message:received", fn);05 — Webhooks
Signed, retried, redeliverable.
The events worth building on are the ones the loop produces — a guide captured, a guide drifting away from the product, content overdue for review. That is where an integration adds something your team would otherwise do by hand.
guide.capturedA new guide finished capture — the start of the loop, before anyone has edited it.guide.driftedA guide’s selectors stopped matching the product it documents. Its pair, guide.drift_cleared, fires when it matches again.content.verification_dueA guide or article went its full review interval without a human re-reading it.content.publishedA guide or article was published; content.retracted is the reverse.conversation.resolvedA person or the AI agent resolved a support conversation or ticket. Fires on the transition only, and carries no message text.experience.completedAn end user finished a tour, program or survey. Dismissing one is not completing it.contact.createdA contact was created by any path — widget, API, import or sync — carrying identifiers only, never the email address.Signing secrets are shown once and encrypted at rest. Deliveries are signed, retried with backoff, and redeliverable from the dashboard — so a bad deploy on your side does not silently lose a day of events.
06 — Clients and stack
What you would be integrating with
Clients
- Widget
- Single snippet or JS API
- Help center
- Server-rendered, your domain
- Browser extension
- Manifest V3 for Chrome and Edge — store listings coming soon
- Desktop
- Tauri 2, Windows and macOS — built, not yet released
- Mobile SDKs
- iOS, Android, Flutter, React Native — built, not yet published
Platform
- Application
- Laravel 13 / PHP 8.5
- Frontend
- Vue 3, TypeScript strict, Tailwind
- Data
- PostgreSQL 18 + pgvector, Redis
- Realtime
- Laravel Reverb websockets
- Domain surface
- 127 models, 431 API routes
Honest limits
The docs are young, and the API is unversioned in practice.
- The developer docs are young. The rendered API reference, the widget guide and the webhook reference are live at docs.cairn.how; long-form integration guides beyond that are not written yet. The OpenAPI specification remains the authoritative contract.
- The API is pre-launch and we have made no backwards-compatibility promise yet. Endpoints are stable in practice, but we will not claim a versioning policy we have not had to honour.
- The OAuth app platform has no public directory and no review process — installs are private today.
- Cairn does not host an MCP endpoint. You run the server yourself, beside your MCP client or on your own infrastructure — and it is not on npm yet. The release is coming soon.
- No SDK for the REST API in any language beyond the generated types. If you want a client library, tell us which language and it becomes a real priority rather than a guess.
Get a key and point your own agent at it.
API keys are created in workspace settings, and the MCP server runs on one. If the integration you need is not there, tell us before you build a workaround.