Schedule user account deletion
- Sandbox: available
- Staging: available
- Production: unknown
Schedules deletion of the caller's own account. The account is not deleted right away: it stays until the scheduled date, and signing in again before then cancels the deletion.
Auth: bearer token of the user who deletes their own account. Scope: the caller's own User, in the project of the token.
Behaviour
days(0 to 90, default 30) sets how many days from now the account is due.wipe(defaultfalse) is recorded on the request.- Ovok signs the user out of all sessions, then records the deletion date on the User. Calling the route again resets the date.
- A job runs every day at midnight. For each User whose date has passed, it deletes the project membership, the profile (Patient or Practitioner) and the User.
- The job does not purge medical data yet, so
wipehas no effect on what is deleted. - Ovok sends a confirmation email (
PATIENT_ACCOUNT_DELETIONfor a Patient,ACCOUNT_DELETIONotherwise). A failed email does not fail the request. - A successful login on the account (
POST /v2/auth/login, or the tenant login routes) removes the scheduled deletion. - The response holds
scheduled(the due date, ISO 8601) and the updateduser, without its password hash.
Example
curl -X DELETE 'https://api.sandbox.ovok.com/auth/delete' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' \ -H 'Content-Type: application/json' \ -d '{ "days": 30, "wipe": false }'bearerAuthorizationBearer <JWT>application/json- body
days?integerAfter how many days the user should be deleted.
0 <= value <= 9030wipe?booleanDeletes all medical data related to the user. If true, all medical data of the user will be deleted at the time of deletion. By default, this is false.
falseUser account deletion confirmation.
application/json- response
scheduled?stringHas the user account been scheduled for deletion.
user?User resource.
curl -X DELETE 'https://api.sandbox.ovok.com/auth/delete' \ -H 'Content-Type: application/json' \ -d '{}'{ "scheduled": "string", "user": { "resourceType": "User", "id": "string", "firstName": "string", "lastName": "string", "email": "user@example.com", "project": { "reference": "string", "display": "string" }, "meta": { "versionId": "string", "lastUpdated": "string", "author": { "reference": "string", "display": "string" }, "project": "string", "compartment": [ { "reference": "string" } ] } }}Log out (server-side token revocation) POST
Signs the caller out on the server: the access token in the `Authorization` header stops working for every authenticated route, although it has not expired. **Auth:** bearer token. A missing or invalid token gives 401. ## Behaviour - Ovok adds the token to a denylist. The entry lasts for the rest of the token's lifetime (its `exp` claim), so the list never outgrows the set of live tokens. - Only this access token is revoked. The refresh token is not touched here; to end other sessions use `DELETE /auth/session/{option}`. - The call is idempotent: repeating it with the same token returns 204 with no further effect. A token without an `exp` claim, or one that has already expired, is ignored. - If the denylist store is unavailable the call still returns 204, and the token stays valid until it expires. Clear the local session as well. - The response has no body (204 No Content). - The route is available at both `/auth/logout` and `/v1/auth/logout`. ## Example ```bash curl -X POST 'https://api.sandbox.ovok.com/v1/auth/logout' \ -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE3NjcyNjg4MDAsImV4cCI6MTc2NzI3MjQwMH0.Ql3B_ztDvctlyZ2z0vp4sl3ExXRQGkzmxdmTAqxNzZk' ```
Login POST
Signs a user in with email and password for the project that owns a client application, and returns an access token and a refresh token. New integrations should use the tenant login routes (`/auth/tenant/Patient/login/start` and `/auth/tenant/Practitioner/login/start`) instead. **Auth:** none. The email and password are the credential, and `clientId` names the project. **Scope:** the project that owns the `ClientApplication` with the given `clientId`. ## Behaviour - Ovok looks up the account by email in the client application's project. If a Patient and a Practitioner share the email in that project, one of them is picked and which one is not defined. - The account type's login switch must be on: the project setting `PATIENT_LOGIN_ENABLED` or `PRACTITIONER_LOGIN_ENABLED`. Both default to on. It is checked once the password is right, so its 403 never tells which emails have an account. - A wrong password and an unknown email give the same 401 `Invalid email or password.`, so the response does not tell you which one was wrong. An unknown `clientId` gives a 400. - After 5 failed sign-ins for one email within 15 minutes, that email's sign-ins answer 429 with `Retry-After` for 15 minutes, the right password included, whether or not the email has an account. A successful sign-in resets the count. - If Medplum's own login rate limit is hit, you get a 429 instead of a 401. Wait and retry. - Callers without a token may send at most 10 requests per minute from one IP address. - A successful login cancels a pending account deletion (`DELETE /auth/delete`). - This route has no MFA step. Use the tenant login routes for users with MFA enrolled. - The access token lasts one hour (`expiresIn` is in seconds). Use `POST /auth/refresh-token` to renew it. ## Example ```bash curl -X POST 'https://api.sandbox.ovok.com/v2/auth/login' \ -H 'Content-Type: application/json' \ -d '{ "email": "max.mustermann@example.com", "password": "Ex4mple-Passw0rd", "clientId": "c3499c27-2973-0a7f-807e-fb8676a92dcb" }' ```