# Get current project settings

Canonical page: https://docs.ovok.com/api/projects/get-current-project-settings

`GET /v1/project/settings`

Returns the settings of your current project: the on/off settings and the text settings such as app URLs and default access policies.

**Auth:** bearer token. The caller must be a Practitioner, a project admin, or hold the System Owner access policy.
**Scope:** the caller's project (from the token).

## Behaviour

- Settings are read from `Project.setting[]` by name.
- `settings` always has every on/off key. A key that is not stored, or not stored as a boolean, is `false`.
- `values` always has every text key. A key that is not stored, or is blank, is `null`.
- `DEFAULT_PATIENT_ACCESS_POLICY` is read from `Project.defaultPatientAccessPolicy`, as `AccessPolicy/<id>`: the policy patient registration and patient invites give a new patient.
- Entries of `Project.setting[]` with other names are not returned.

## Saved and effective values

`settings` cannot tell a switch turned off from one never saved. Two records, with every on/off key, can:

- `overrides`: the saved value, `true` or `false`, or `null` when none is saved (or it is not stored as a boolean).
- `effectiveSettings`: what Ovok applies. The saved value, else the default below, and off while the feature lacks what it needs (the column on the right).

| Key | Default | Also needs |
| --- | --- | --- |
| `PATIENT_LOGIN_ENABLED`, `PRACTITIONER_LOGIN_ENABLED`, `RELATED_PERSON_LOGIN_ENABLED` | on | |
| `PATIENT_INVITATION_ENABLED` | on | `DEFAULT_PATIENT_ACCESS_POLICY`. |
| `PRACTITIONER_INVITATION_ENABLED`, `RELATED_PERSON_INVITATION_ENABLED` | on | |
| `PATIENT_REGISTRATION_ENABLED` | on | `DEFAULT_PATIENT_ACCESS_POLICY`, naming a policy that can be read. |
| `PRACTITIONER_REGISTRATION_ENABLED` | off | `DEFAULT_PRACTITIONER_ACCESS_POLICY` (or `CLINICIAN_INVITE_ACCESS_POLICY`): an AccessPolicy of this project. |
| `CLINICIAN_INVITE_ON_BUSINESS_EMAIL` | off | Effective `PATIENT_REGISTRATION_ENABLED`, and the default practitioner access policy as above. |
| `CONTENT_ENABLED`, `MAILING_ENABLED` | off | Markers the Console sets; Ovok does not act on them. |
| `SIGNALS_SEND_AUTO` | off | A Signals tenant of the project's own. Observations created through FHIR go to it, and a resident's first one enrols the resident in Signals; ingest readings go there on their own. |
| `SIGNALS_ANNOTATE_OBSERVATIONS` | as `SIGNALS_SEND_AUTO` | A Signals tenant of the project's own. Signals' alerts and episodes are written into the project as `DetectedIssue` and `Flag`, and an alert's reading gets its `interpretation`. Project roles need read on `DetectedIssue` and `Flag` to see them. |

- App URLs are not folded in: they are in `values`, and a flow that needs a missing one reports it, for example an invite answers 409 `app_url_not_configured`.
- Some routes need more. The sharing invites (`/v1/invites`) also need practitioner sharing on, set through the patient-sharing settings.
- With `PRACTITIONER_LOGIN_ENABLED` off, a practitioner who is a project admin keeps refreshing an open session, so they can turn it back on.
- A default access policy that cannot be read at that moment counts as missing, as it does for the flows themselves.
- Every key is read from the first `Project.setting[]` entry of its name.

## App URLs

`PATIENT_APP_URL` and `PRACTITIONER_APP_URL` are the app roots that links in emails are built on: `https://app.example.com` gives `https://app.example.com/setpassword/<id>/<secret>`.

- Resolution order, per audience: the project's setting, then the parent project's, then the legacy setting (`PATIENT_SIGNUP_URL` or `CLINICIAN_DASHBOARD_URL`, on the project then its parent), then the request `Origin` for flows that allow it, then the deployment default.
- For set-password and invite links, only the origin of `PATIENT_SIGNUP_URL` is used: `https://app.example.com/register` gives `https://app.example.com`, and `vitalwise://register` gives `vitalwise://`. Set `PATIENT_APP_URL` if the patient app lives under a path.
- The continue-as-patient link (a business-address sign-up turned into a clinician invite) uses `PATIENT_SIGNUP_URL` in full whenever it is set, ahead of `PATIENT_APP_URL`.
- An app URL is an https URL on any host (http only on localhost), or an app deep link `scheme://[host][/path]`: `vitalwise://` gives `vitalwise:///setpassword/<id>/<secret>`. A web URL on this API's own host is refused, and a stored one is skipped when an email is sent.
- Only the canonical form is stored and used, without a trailing slash. Userinfo, a query, a fragment, an opaque `scheme:path`, and web, script or local schemes used as a deep link (`javascript:`, `data:`, `file:` and others) are refused on write and skipped on send.
- An invite with no app URL for its audience answers 409 `app_url_not_configured` and creates nothing.

## Example

```bash
curl -X GET 'https://api.sandbox.ovok.com/v1/project/settings' \
  -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk'
```