Syncanix with Next.js

Next.js derives routes from the filesystem. Discovery walks both the App and Pages routers and turns file paths into request paths — dynamic segments, catch-alls, and route groups included.

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/api/orders/[id]/route.ts   → GET /api/orders/[id]
export async function GET(req: Request) { /* … */ }

// app/api/orders/[id]/refund/route.ts → POST /api/orders/[id]/refund
export async function POST(req: Request) { /* … */ }

The extractor derives paths from the filesystem for both routers: dynamic segments like [id], catch-all segments, and route groups are all resolved, and the exported HTTP-verb functions determine each capability’s method.

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