Syncanix with Express

Express apps compose routes across files — a router defined in one module, mounted under a prefix in another. Syncanix discovery follows those mounts statically and emits full paths, so the catalog matches what your API actually serves.

What discovery reads

Discovery is static — it reads your source, not your traffic. It composes full request paths across files, so mounted prefixes are part of every extracted route:

// app.ts
app.use('/api', ordersRouter);

// orders.router.ts
const ordersRouter = Router();
ordersRouter.get('/orders/:id', getOrder);      // → GET /api/orders/:id
ordersRouter.post('/orders/:id/refund', refund); // → POST /api/orders/:id/refund

The extractor follows app.use(prefix, router) mounts and Router().use() chains across files — including default-imported routers — so a route declared as /orders/:id inside a router mounted at /api is catalogd as GET /api/orders/:id.

Run discovery

From the repository root, run the init command. It detects the framework automatically, asks for consent before any LLM enrichment, and writes a deterministic catalog:

$ npx syncanix init
✓ detected framework
✓ scanned routes
✓ wrote .syncanix/catalog.json
→ review your capabilities in the dashboard

Review the catalog

The catalog at .syncanix/catalog.json lists every capability discovery found — method, path, and the enriched description your users will see. Review it like code before uploading: it is the contract your chat surface and MCP server expose.

Ship the surface

Once the catalog is uploaded, embed the widget for in-app chat and connect the per-tenant MCP server for Claude, ChatGPT, and Cursor. Every write action stays permission-gated, confirmed, and audited.

Next steps