# Permanently deletes a user account from the system

`DELETE /api/users/{username}`

- **Products:** Operator (`FOH`)
- **Features:** Front of House Generic Access (`FOHGENERIC`)

HTML version: [Permanently deletes a user account from the system](https://support.gladstonesoftware.cloud/reference/users/permanently-deletes-a-user-account-from-the-system)

## Overview

Retires a staff (back-office) user account so it can no longer be used. Returns `204 No Content` with no body. There is no undo through this API, and the username is never released — plan for that before you call it.

What actually happens is a soft delete of the main account record: `isActive` is set to `false` and `isDeleted` to `true`, and the account itself stays in place. The account's legacy system-user record, which carries its site assignment and password-reset flag, is permanently removed. There is no "undelete" endpoint, and [Updates the details and settings for a specific administrative user](updates-the-details-and-settings-for-a-specific-administrative-user.md) will not restore a deleted account cleanly because the system-user record it needs is gone.

The consequence that catches integrators out: because the account survives, its username stays taken. [Creates a new administrative user account in the system](creates-a-new-administrative-user-account-in-the-system.md) checks for the username without excluding deleted accounts, so re-creating a user you deleted returns `409`, permanently. If you may need the account back, set `isActive: false` through the update endpoint instead — that is reversible.

After deletion the account disappears from [Retrieves all administrative users configured in the system](retrieves-all-administrative-users-configured-in-the-system.md) but is still returned by [Retrieves detailed information for a specific administrative user](retrieves-detailed-information-for-a-specific-administrative-user.md) with `isDeleted: true`, which is how you confirm the call took effect.

## Endpoint

`DELETE {base_url}/api/users/{username}`

`{base_url}` is the environment URL issued to your integration. See [Authenticating with Gladstone APIs](../../guides/authenticating-with-gladstone-apis.md).

## Path parameters

| Name | Type | Required | Description |
|------|------|----------|-------------|
| `username` | string | Yes | The sign-in name of the account to retire, as returned in `[].username` by [Retrieves all administrative users configured in the system](retrieves-all-administrative-users-configured-in-the-system.md). Matched exactly. The username remains reserved after the call and cannot be reused. |

## Sample request

```bash title="cURL"
curl -X DELETE '{base_url}/api/users/{username}' \
  -H 'Authorization: Bearer {accessToken}' \
  -H 'X-Use-SSO: true'
```

## Errors

| Status | Meaning | When |
|--------|---------|------|
| `400` | Bad request | The username in the path is empty: `Id cannot be null or empty`. Also returned, with no body, when the delete loses a concurrency check because the account was modified by someone else between read and write — retry in that case. |
| `404` | Not found | No account exists with that username: `User {username} cannot be found when calling Delete`. Deleting an already-deleted account still succeeds on [numeric-role tenants](retrieves-all-administrative-users-configured-in-the-system.md), because the account itself stays in place. |
| `409` | Conflict | The delete was refused — typically because another record still refers to the legacy system-user record being removed. Returned with no body. |
| `500` | Internal server error | Any other unexpected server-side failure, including, on ObjectId-role tenants, the two halves of the delete failing to complete together, which can leave the account partly deleted. Returned with no body. |