Reset user password with the information from the email.
- Sandbox: available
- Staging: available
- Production: unknown
Sets a new password using the id and secret from a reset email. Use it when your app handles the reset itself instead of sending the user to the emailed link.
Auth: none. The reset request id and secret are the credential.
Behaviour
- The
idandsecretcome from the email sent byPOST /v2/auth/reset-password. Thepasswordis the new password. - The password must have at least 12 characters, not counting spaces at either end, and must not be on Ovok's list of common and breached passwords. Any character is allowed and none is required. A refused password answers 422 with the error on
password. - An invite link (from
POST /auth/inviteor a practitioner invite) sets a password for 7 days after it was sent. After that it answers 410This invite link has expired. Ask for a new invite., and inviting the user again sends a fresh link. Reset links are not limited this way. - A request can be used once. Ovok marks it used before it changes the password, so a request whose password change then fails cannot be retried and the user must ask for a new email.
- Setting the password also marks the user's email as verified, because the secret came by email.
- The response is a minimal
UserwithresourceType,idandemail.
Example
curl -X POST 'https://api.sandbox.ovok.com/v2/auth/reset-password/process' \ -H 'Content-Type: application/json' \ -d '{ "id": "c3499c27-2973-0a7f-807e-fb8676a92dcb", "secret": "k3J9xQ2mV7", "password": "Ex4mple-Passw0rd" }'application/json- body
id*stringThe ID UserSecurityRequest.
secret*stringThe secret of the UserSecurityRequest.
password*stringThe new password.
12 <= length <= 128User resource with id and email.
curl -X POST 'https://api.sandbox.ovok.com/v2/auth/reset-password/process' \ -H 'Content-Type: application/json' \ -d '{ "id": "string", "secret": "string", "password": "stringstring"}'Send reset password email POST
Sends a password reset email to a Patient, a RelatedPerson (carer) or a Practitioner. The answer is the same whether or not an account exists, so the route cannot be used to find out which emails are registered. **Auth:** none. **Scope:** for a Patient or RelatedPerson, the project that owns `clientId`. For a Practitioner, the account is found by email across projects. ## Behaviour - `type` is `Patient`, `RelatedPerson` or `Practitioner`. `clientId` is required when `type` is `Patient` or `RelatedPerson` and is ignored for a Practitioner. - The response is always a FHIR `OperationOutcome` saying "If the user exists, a password reset email has been sent." It is returned for unknown emails, unknown client IDs and accounts that could not be mailed. - When the account exists, Ovok creates a reset request, which replaces any earlier open reset request for the user, and emails the user. Patients and RelatedPersons get the `PATIENT_RESET_PASSWORD` template and Practitioners the `RESET_PASSWORD` template. - The email carries a link `<app URL>/setpassword/<id>/<secret>` plus the request `id` and `secret`. The app URL is the project's patient app URL for a Patient or RelatedPerson, and its practitioner app URL for a Practitioner; if none is set, the request's `Origin` is used when it is an allowed one. - A Practitioner who is a member of more than one project gets a link to the Ovok platform app instead of a project's app URL. - If no app URL can be found, the email still goes out, without a link. The `id` and `secret` in it can be sent to `POST /v2/auth/reset-password/process`. - If a Practitioner has several accounts, the first one found is used. ## Example ```bash curl -X POST 'https://api.sandbox.ovok.com/v2/auth/reset-password' \ -H 'Content-Type: application/json' \ -d '{ "email": "max.mustermann@example.com", "clientId": "c3499c27-2973-0a7f-807e-fb8676a92dcb", "type": "Patient" }' ```
List alerts, or the episodes they were folded into GET
The dashboard view. By default this is one row per breach, in v1's alert shape plus every nest alert field, inside v1's paginate envelope (`items`, `totalItems`, `page`, `totalPages`, …) with nest's `nextCursor` beside it. Page with v1's `page` and `limit` (a page may start at most 10000 rows in), or walk with `cursor`: pass `nextCursor` back verbatim. `sort` is v1's `time-desc` (the default) or `time-asc`; `ids` narrows to those patients. It works whether or not the tenant has `episodicAlerts`. Without `project` it is tenant-wide: a per-facility view must send `project`, which keeps only patients stamped with it. `?episodes=true` answers with episodes instead, as `{items, nextCursor}`: one row per clinical event, which opens on the first breaching reading, absorbs the rest, and closes on recovery, on going stale, or by hand. That grain REQUIRES `project`. It defaults to the tenant's `feedCodes` (`PATCH /api/tenant`), every code when it lists none; alerts have no code default. `codes`, `since` and `acknowledged` filter either grain. `until`, `page` and `ids` are alerts only: sending one with `episodes=true` is a 422, not a filter that silently did nothing. `status` reads ACTIVE/RESOLVED for alerts and OPEN/CLOSED for episodes. Episodes are newest first by `sort`: `openedAt`, the default, or `lastFiringAt`, the newest firing reading (the opening, for an episode that has none). `since` and the cursor use the same time. `openedAt` never changes, so walking every page lists each episode once. On `lastFiringAt` an episode that fires mid-walk moves above the cursor: it is never listed twice, but that walk misses it. A `sort` value from the other grain is a 422. ### Through ovok - **Who can call it:** Manager apps, and users whose access policy grants the capabilities. - **Capabilities, all required:** `signals_alerts:read`. Project admins have every capability; client applications get no admin bypass. - ovok sets `project` to your project, so you can leave it out. - If your access covers only some patients (anyone but project admins, manager or submitter apps, and anyone whose Patient access has no criteria), name them with `patientId` or `ids`, each one you can read, at most 100. Signals then pages over just those patients, so pages and totals stay true. A patient is named by its Signals id, or by its Medplum Patient id where Signals takes a `refId`; ovok asks Signals which patient a Signals id is.