Skip to main content

DEFAULT_PRACTITIONER_ACCESS_POLICY

The AccessPolicy that a new practitioner receives when Ovok creates their account on your behalf: through self-registration, a business-email sign-up, or one of the invitation routes.

TypeText setting
Change withPUT /v1/project/settings/values/DEFAULT_PRACTITIONER_ACCESS_POLICY
ValueAccessPolicy/<id> of an AccessPolicy in this project, or null to remove it
Who can change itProject admin
When unsetRoutes that need it refuse with 409; others create the practitioner without a policy
Set on new projectsNot set by any project-creation route
InheritedNo. A child project reads only its own value.

Why it exists​

A project membership with no AccessPolicy is not limited by one. For that reason Ovok will not create a practitioner without a policy where it can avoid it: registration, business-email sign-up and the patient and practitioner invitations all refuse until this setting resolves to a valid policy. Set it once, to a policy that holds only what a brand-new practitioner should be able to do.

Set it​

curl --request PUT \
  --url 'https://api.sandbox.ovok.com/v1/project/settings/values/DEFAULT_PRACTITIONER_ACCESS_POLICY' \
  --header "Authorization: Bearer ${OVOK_TOKEN}" \
  --header 'Content-Type: application/json' \
  --data '{"value":"AccessPolicy/practitioner-policy-id"}'

The response is the full settings record; the value appears under values. Send {"value":null} to remove it.

ResponseMeaning
422 with code INVALID_SETTING_VALUEThe value is not AccessPolicy/<id>, no such policy exists, or the policy belongs to another project.
400 with code UNKNOWN_SETTINGThe key is misspelled. The body lists acceptedKeys.
403The caller is not a project admin.
409The project changed during the write. Read the settings again and retry.

The check is strict on purpose: a policy from another project is never accepted, so a setting cannot grant access that the project does not own.

Where Ovok reads it​

RouteWhat it does with the policyWhen it is missing or invalid
POST /auth/tenant/Practitioner/registerGives it to the new practitioner.409, error practitioner_registration_not_configured
POST /auth/tenant/Patient/register with business-email sign-ups onGives it to the invited clinician.Falls back to a normal patient registration, silently.
POST /v1/invites/practitioner and /acceptGives it to the invited practitioner.409, error invitation_not_configured
POST /v1/projects/me/membersUses it as the base policy when the request carries access entries.409, error invitation_not_configured, only when access is sent

Two invitation routes do not read it:

  • POST /auth/invite with type Practitioner creates a practitioner with no AccessPolicy.
  • POST /v1/slim/invite/practitioner uses the accessPolicyId you send in the request.

Gotchas​

  • A parent's policy id does not work in a child project. Creating a child with POST /v1/slim/project/child copies the parent's AccessPolicies under new ids. Read the child's own policies and use those ids.
  • Changing it does not touch practitioners who already have an account. It applies to practitioners created afterwards.
  • A set but broken value does not fall back. If the policy is deleted or cannot be read, routes behave as if the setting were unset. They do not try the older setting below.
  • The reader is more forgiving than the writer. Ovok will read a bare id that was stored by hand, but PUT requires the AccessPolicy/ prefix.
  • Error identifiers are not in one field. practitioner_registration_not_configured and invitation_not_configured are in error; INVALID_SETTING_VALUE and UNKNOWN_SETTING are in code.

Older setting: CLINICIAN_INVITE_ACCESS_POLICY​

Projects that configured clinician invitations before this setting existed may have CLINICIAN_INVITE_ACCESS_POLICY. Ovok uses it only when DEFAULT_PRACTITIONER_ACCESS_POLICY is absent or blank. It is written the same way (PUT /v1/project/settings/values/CLINICIAN_INVITE_ACCESS_POLICY) and follows the same validation. New integrations should set only DEFAULT_PRACTITIONER_ACCESS_POLICY.

Business-email sign-ups​

With CLINICIAN_INVITE_ON_BUSINESS_EMAIL on, a patient registration with a work email invites that person as a practitioner and gives them this policy. If the policy is missing or invalid the invitation does not go out and the person is registered as a patient, silently. See that page for the full list of requirements.