Keeping your catalog fresh

Your capability catalog describes your API at the moment you ran discovery. APIs move — so freshness is a loop, not a one-off: re-run discovery on change, automate it in CI, and let runtime drift detection catch anything that slipped through.

Re-run discovery whenever the API changes

Re-running init is safe by design: extraction is deterministic, the catalog file (.syncanix/catalog.json) is rewritten from your current code, and the refreshed catalog uploads to the same workspace. There is no migration step — the re-run IS the update.

npx syncanix init

Your curation survives the re-run: entries listed in .syncanixignore are excluded on every run because the file lives in your repo, and any per-capability overrides you made in the dashboard are keyed to the capability and re-apply after a rescan — that survival is covered by an integration test, not a convention.

Automate it: discovery in CI

In CI, run init non-interactively with --yes and authenticate with the SYNCANIX_API_KEY environment variable (mint a key in the dashboard and store it as a CI secret — the same key syncanix login would write locally). A minimal GitHub Actions workflow:

# .github/workflows/syncanix-catalog.yml
name: Refresh Syncanix catalog
on:
  push:
    branches: [main]
jobs:
  refresh:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - run: npx syncanix init --yes
        env:
          SYNCANIX_API_KEY: ${{ secrets.SYNCANIX_API_KEY }}

Run it on pushes to your main branch (or only when API code paths change, using your CI path filters). The job re-extracts, re-uploads, and your assistant picks up the refreshed catalog — no deploy of Syncanix itself involved.

Runtime drift detection (Node SDK)

Even with CI in place, an endpoint can ship that discovery never saw. The Node SDK watches real traffic for exactly that: it subscribes to Node’s built-in HTTP diagnostics channel — no monkey-patching, zero overhead when idle — and compares each incoming request against the known capability set.

Requests that match no known capability emit a deduplicated new-endpoint drift event, which the SDK uploads to your workspace — so the dashboard shows you endpoints serving production traffic that your catalog does not know about. Treat a drift event as a prompt to re-run discovery.

Monorepos and polyglot codebases

Run init once from the repository root. Discovery detects every framework stack it finds — across workspaces and across languages — extracts each one, and merges the results into a single catalog, so a monorepo with, say, a NestJS API and a FastAPI service produces one combined capability set. If a stack is misdetected, pin it with --framework.

Next steps