Skip to main content

Organisations

Organisation and member management

📄️List organisations the current user can switch into

List organisations the current user can switch into. Each row is an organisation the caller holds an ACTIVE membership for, and the acting tenant's organisation comes first. Organisations in tenants that are not ACTIVE are omitted — including the acting one: PLT-477 gates both membership resolvers on tenant status, so a non-ACTIVE tenant can no longer be acted in at all and the earlier acting-tenant exemption is gone. The list is empty when the acting tenant contributes no visible organisation, even if other tenants did produce rows, so a foreign tenant can never occupy the first position. The payload is deliberately the switch-target projection (`id` and `name` only); use `GET /api/organisations/{id}` for the full organisation record.

📄️Get organisation details

Get organisation details. This is the full organisation record, and the endpoint to use for the fields `GET /api/organisations` does not return — that list is the switch-target projection (`id` and `name` only). Access is the same audience as that list: the handler gates on an ACTIVE membership in the organisation (`resolveOrgAccess`), and the list only ever returns organisations you are an ACTIVE member of — so every caller affected by the narrowing can call this. The `org.settings.view` marker below describes the intended administrative permission; the GET handler does not currently enforce it.