Default AccessPolicies
Default policies give newly created patients and practitioners a starting authorization policy. They are applied when an account or membership is created; they do not rewrite access for people who already belong to the project.
| New member | Where the default comes from | If it is missing |
|---|---|---|
| Patient | The project's defaultPatientAccessPolicy field | Patient registration and invitation flows that require it refuse to create the patient. |
| Practitioner | The DEFAULT_PRACTITIONER_ACCESS_POLICY project setting | Routes that require it return a configuration error; some legacy routes create the practitioner without a policy. |
Both policies must belong to the project where the new member is created. A policy ID from a parent project is not a substitute for the child project's own policy.
Default patient policy
Ovok reads defaultPatientAccessPolicy from the project when creating a patient through registration, invitation, and social sign-in flows. There is no project-settings endpoint for this field, and project-creation routes do not populate it automatically. Configure it before enabling patient onboarding. The patient registration switch does not replace the policy requirement.
New Google and Apple first sign-ins receive the project's default patient policy. Older affected social-sign-in memberships were backfilled where the project had a usable default policy; if an older project has no default configured, review those memberships before relying on patient scoping.
Patient invitation and registration flows have separate switches and route behavior. See patient registration, patient invitations, and set up your project.
Default practitioner policy
Set DEFAULT_PRACTITIONER_ACCESS_POLICY to AccessPolicy/<id> for an AccessPolicy in the same project. Use a policy that is safe for a newly registered practitioner before turning on practitioner self-registration or invitation flows that depend on it.
| Flow | Policy behavior |
|---|---|
| Practitioner self-registration | Assigns the default practitioner policy. A missing or invalid policy blocks registration. |
| Business-email sign-up that becomes a clinician invitation | Assigns the default practitioner policy. If required invitation configuration is missing, the flow can fall back to ordinary patient registration. |
POST /v1/projects/me/members with access entries | Uses the default practitioner policy as the base, then adds the explicitly referenced policies. |
POST /v1/projects/me/members without access | Does not apply the default; the new member has no AccessPolicy and can reach the project broadly. |
POST /auth/invite with type: Practitioner | Legacy exception: does not read this setting and creates the practitioner without a policy. |
POST /v1/slim/invite/practitioner | Uses the accessPolicyId supplied to that route. |
The legacy CLINICIAN_INVITE_ACCESS_POLICY key may be read for older projects when the current key is absent or blank. New integrations should configure only DEFAULT_PRACTITIONER_ACCESS_POLICY.
Defaults are project-local and not retroactive
Child projects need their own patient and practitioner defaults. A child project may receive cloned AccessPolicies with new IDs, so read the child project's policies and configure references using those IDs. Defaults are not inherited from the parent.
Changing a default affects later account creation. It does not change existing memberships. To change an existing member's access, update that membership's policy assignment and review the resulting effective access.