در حال بارگذاری…
Takes a pending account deletion back, restoring the account completely. Valid at any point inside the grace period.
auth:sanctum)throttle:5,1None. The subject is always the caller.
No password and no SMS code, deliberately. Cancelling is the restorative direction: it destroys nothing and puts the account back exactly as it was, so the bearer token is sufficient. A second factor would only give a user racing their own deletion deadline a way to fail — the one outcome the grace period exists to prevent. Requesting the deletion (POST /api/v1/auth/delete-account) is where both factors are demanded.
Requesting a deletion revokes every session the user held, so the token used here is normally one minted by a fresh POST /api/v1/auth/login, which keeps working during the window.
None.
DELETE /api/v1/auth/delete-account
Authorization: Bearer {token}
{
"message": "Your account deletion has been cancelled."
}
deletion_requested_at and deletion_scheduled_at are cleared, any unused confirmation code is dropped, the account reappears in GET /api/v1/users and in training-service search, and an account_deletion_cancelled notification is delivered. The session used to cancel stays valid; sessions revoked when the deletion was requested are not restored.
| Status | Description | Reference / Example |
|---|---|---|
| 401 | Not authenticated | Authentication error |
| 404 | No deletion is pending, or the account is already disposed of | { "error": "Item not found." } |
| 429 | Too many requests | Rate-limit error |
404 rather than 409: an account whose grace period has already elapsed and been swept has nothing left to restore, and the response confirms no state the caller has not already been told about.
POST /api/v1/auth/delete-account — request the deletionGET /api/v1/auth/me — read the pending-deletion timestamps