DEVELOPERS

The API is the product.
Start there.

Everything the console can do, the API can do, because the console is just a client. Publish state, declare foundries and reactions in YAML, subscribe to changes, and read the whole model back.

ONE PUBLISH

Send a document. Watch the system run.

That publish is a catalyst. The deals-from-calls foundry runs, records are forged, and any reaction subscribed to the resulting state fires. No screen was involved.

curl -X POST https://api.caelion.app/v1/publish \
  -H "Authorization: Bearer $CAELION_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "meeting.transcript",
    "account_hint": "acme-industrial.com",
    "body": "..."
  }'

SURFACE

Everything the console can do. Nothing it can do that you cannot.

POST /v1/publish
Send any document. Foundries decide what it becomes.
GET /v1/state/{entity}/{id}
Read a record with its full history and provenance.
GET /v1/search?q=
Semantic search across every record and document.
PUT /v1/foundries/{name}
Declare or update a foundry from YAML.
PUT /v1/reactions/{name}
Declare or update a reaction from YAML.
GET /v1/subscribe
Server-sent events for every state change, filterable.
MCP
mcp.caelion.app exposes the same surface to any MCP client.

DECLARE, DO NOT CLICK

Foundries and reactions are YAML.

Version them. Review them. Deploy them from CI. A reaction is a file, and the file is the documentation.

This site publishes /llms.txt so assistants can read what Caelion is without scraping.

Read llms.txt 
kind: reaction
name: quiet-deal-nudge
when:
  entity: deal
  condition: stage in [proposal, negotiation] and idle > 9d
agent: seller
do:
  - research: account.recent_news
  - draft: { channel: email, to: deal.champion, tone: direct }
  - require_approval: owner
  - publish: gmail

EARLY ACCESS

Build it with us.

Early-access teams get API keys, the SDKs and a Slack channel with the people building it.

Get early access Read the API first