RidgeCRM Developer Docs

Start Here

Architecture

How RidgeCRM requests, org context, metadata, and extension points fit together.

Runtime stack

RidgeCRM runs as a SvelteKit app with Prisma as the data access layer. Public marketing pages, authenticated CRM pages, Setup, admin pages, and `/api/v1` endpoints all live in the same project.

Production should document the SvelteKit API as canonical. The old Express `server.js` and Swagger path are not the deployed developer story unless you intentionally revive that service.

  • Public site: `src/routes/(site)`
  • Authenticated app: `src/routes/(app)/app`
  • Setup platform: `src/routes/(app)/app/setup`
  • API v1: `src/routes/api/v1`
  • Platform services: `src/lib/services`
  • Trigger registration: `src/lib/triggers/registerHandlers.js`

Request context

Server handlers use request locals to understand the signed-in user and organization. Browser app routes typically rely on sessions and org cookies. Programmatic API calls use Bearer JWTs and often require `X-Organization-ID`.

http

Required API headers

Authorization: Bearer <jwt>
X-Organization-ID: <organization-id>
Content-Type: application/json

Extension points

  • Use automation rules for declarative if-this-then-that behavior.
  • Use platform triggers when code, queueing, or an outbound webhook should run around record changes.
  • Use custom web components when record pages or workspace apps need UI that RidgeCRM does not ship by default.
  • Use `/api/v1/platform/*` to create tooling around custom objects, records, fields, triggers, and deployment.