IRironcladapp
Users

Delete a User

Delete a user on Ironclad. If the deletion is successful, all active workflows associated with the deleted user should be automatically reassigned to the default user within the admin group. To learn how to set a default user, see the Manage Groups guide.

If the company has enabled the setting that prevents deleting non-deactivated users, the user must be deactivated (via active: false) before they can be deleted.

OAuth Scope required: scim.users.deleteUsers

delete/Users/{userId}

Request

  • Base URL
    https://ironcladapp.com/scim/v2
  • URL
    https://ironcladapp.com/scim/v2/Users/{userId}
  • Auth
    API key in header Authorization

Path parameters

userIdstring required

A user's unique id can be identified using the Retrieve all Users endpoint with a filter parameter

Headers

x-as-user-emailstring
Example:jane.doe@test.com

Denotes the actor of the request. When used, the API will take into account this user's permissions and access. This or x-as-user-id is required when the associated token was produced from the Client Credentials grant or with legacy bearer tokens on select endpoints. A token produced from the Authorization Code grant (which is already scoped to a user) may also use this header to act as a different user in the same company, provided the token carries the identity.users.impersonate scope and the token's own user has been granted the API User Impersonation permission. A request that sends this header without both never acts as the named user; depending on the company's configuration it either proceeds as the token's own user or is rejected with a 403. More information about permissions.

x-as-user-idstring
Example:5f0375c4cdc1927a3c5edcd3

Denotes the actor of the request. When used, the API will take into account this user's permissions and access. This or x-as-user-email is required when the associated token was produced from the Client Credentials grant or with legacy bearer tokens on select endpoints. A token produced from the Authorization Code grant (which is already scoped to a user) may also use this header to act as a different user in the same company, provided the token carries the identity.users.impersonate scope and the token's own user has been granted the API User Impersonation permission. A request that sends this header without both never acts as the named user; depending on the company's configuration it either proceeds as the token's own user or is rejected with a 403. More information about permissions.

Response

204 No Content

Changes

No recorded changes to this operation across all 1 revision of this API.