Skip to main content

Disabling or deleting a user

This guide covers the two ways to end a user's access to an organization with the API:

  • Disabling — reversibly suspends access. The user record is kept and can be re-enabled at any time.
  • Deleting — permanently removes the user and their access.
Prerequisites
  • A valid set of API credentials
  • A valid access token (see: Get a token) with the stonal.user.write scope
  • An organization code

Choosing between disabling and deleting

DisablingDeleting
Reversible?Yes — re-enable at any timeNo — permanent
User recordKept (surfaced as disabled)Removed
ScopeThe organization in the request pathThe organization in the request path
Typical useTemporary suspension (leave, offboarding in progress, lost device)Permanent removal

Step 1: Retrieving the user UID

Both operations need the user's UID. Search for the user to get it.

See: Find an existing user

GET /v2/organizations/DEMO/users?pageNumber=1&pageSize=10&q=john.doe@example.com

If the user exists, you'll receive a 200 response with the user's details including their UID and current disabled state.


Disabling a user

How disabling works

Disabling is scoped to a single organization. The operation sets a flag on the user's access in the organization in the request path; the user immediately loses access to that organization's assets, applications, and reports. Their access in any other organization is untouched.

Because a Stonal identity is a single sign-in account shared across every organization the person belongs to, the underlying account is only disabled — preventing sign-in entirely — once the user has been disabled in all of their organizations. As soon as they are re-enabled in any one organization, sign-in is restored.

A few things to keep in mind:

  • Still discoverable — disabled users keep appearing in user listings with disabled: true, so you can find and re-enable them.
  • Eventual revocation — permission checks are cached for up to ~1 minute, so access is fully revoked within ~60 seconds (the same behaviour as deletion).
  • No self-disable — you cannot disable the account you are authenticated as (returns 409).
  • v2 only — the disable and enable endpoints are available on the v2 API.

Disable the user

See: API Specification

POST /v2/organizations/DEMO/users/5dbbc53c-1a22-4f6f-883c-74c04fe905f5/disable
import requests

BASE_URL = "https://api.stonal.io/users"
TOKEN = "<access_token>"

resp = requests.post(
f"{BASE_URL}/v2/organizations/DEMO/users/5dbbc53c-1a22-4f6f-883c-74c04fe905f5/disable",
headers={"Authorization": f"Bearer {TOKEN}"},
)
print(resp.status_code)

Path parameters:

  • organizationCode: Your client code (e.g., "DEMO")
  • uid: UID of the user to disable (e.g., "5dbbc53c-1a22-4f6f-883c-74c04fe905f5")

Possible responses:

  • 204: User has been successfully disabled
  • 404: User to disable does not exist
  • 409: The user cannot be disabled (for example, you cannot disable your own account)

Re-enable the user

To restore access, call the enable endpoint with the same UID. This clears the disabled flag in the organization and, if the user's sign-in account was disabled, restores it so they can authenticate again.

See: API Specification

POST /v2/organizations/DEMO/users/5dbbc53c-1a22-4f6f-883c-74c04fe905f5/enable
import requests

BASE_URL = "https://api.stonal.io/users"
TOKEN = "<access_token>"

resp = requests.post(
f"{BASE_URL}/v2/organizations/DEMO/users/5dbbc53c-1a22-4f6f-883c-74c04fe905f5/enable",
headers={"Authorization": f"Bearer {TOKEN}"},
)
print(resp.status_code)

Path parameters:

  • organizationCode: Your client code (e.g., "DEMO")
  • uid: UID of the user to re-enable (e.g., "5dbbc53c-1a22-4f6f-883c-74c04fe905f5")

Possible responses:

  • 204: User has been successfully enabled
  • 404: User to enable does not exist

Deleting a user

warning

Deletion is permanent and cannot be undone. To revoke access in a way you can reverse, disable the user instead.

See: API Specification

DELETE /v2/organizations/DEMO/users/019619df-4768-76b7-81e3-2c56d374df46
import requests

BASE_URL = "https://api.stonal.io/users"
TOKEN = "<access_token>"

resp = requests.delete(
f"{BASE_URL}/v2/organizations/DEMO/users/019619df-4768-76b7-81e3-2c56d374df46",
headers={"Authorization": f"Bearer {TOKEN}"},
)
print(resp.status_code)

Path parameters:

  • organizationCode: Your client code (e.g., "DEMO")
  • uid: UID of the user to delete (e.g., "019619df-4768-76b7-81e3-2c56d374df46")

Possible responses:

  • 204: User has been successfully deleted
  • 404: User to delete does not exist
  • 409: The user cannot be deleted due to a conflict (for example, a referential constraint)

Notes

  • All operations are organization-scoped and only affect access within the organization in the request path.
  • The user UID must be obtained from a previous search or stored as an external id on your side.
  • Disabling and re-enabling are idempotent — disabling an already-disabled user, or enabling an already-enabled user, succeeds and leaves the state unchanged.
  • Deletion is permanent and cannot be undone; use disabling when you may need to restore access later.

Error Handling

Stonal APIs return a consistent error envelope: { "type", "title", "detail" }. Validation failures (422) replace detail with a per-field errors array.

StatustypeMeaning
400tag:InvalidBody / tag:InvalidContentTypeThe request body or content type is invalid
401tag:UnauthenticatedMissing or expired authentication token
403tag:ForbiddenAccessThe token lacks permission for this resource
422tag:ValidationErrorOne or more fields failed validation (see errors[])
500tag:InternalErrorUnexpected server error
{
"type": "tag:ValidationError",
"title": "Invalid request",
"errors": [
{ "field": "email", "detail": "Email is required" }
]
}