solarOSsolarOS Docs
Api

The public path includes /v1 and every response's meta.version is "v1" (apps/web/src/lib/org-api/responses.ts). Per apps/web/src/lib/org-api/public-docs.ts's versioning-and-schema content: new optional fields may appear on existing responses without a version bump, and GET /api/v1/schema lets you discover tenant-specific Field definitions before creating or updating records with customFields. Request bodies are strict; unknown top-level fields are rejected as validation errors.

TODO(owner, likely engineering): write the full page covering what counts as a breaking vs. additive change in practice, and cross-link the changelog, which is where breaking changes get announced per this repo's CI check (openapi-diff requires a changelog entry on a breaking spec diff; confirm the exact rule in .github/workflows/ci.yml before stating it here).

Was this page helpful?