{"id":197506,"date":"2026-10-08T17:44:43","date_gmt":"2026-10-08T08:44:43","guid":{"rendered":"https:\/\/support.questetra.com\/?p=197506"},"modified":"2026-10-08T17:44:46","modified_gmt":"2026-10-08T08:44:46","slug":"user-deletion-api","status":"publish","type":"post","link":"https:\/\/support.questetra.com\/en\/developer-blog\/user-deletion-api\/","title":{"rendered":"Managing Former Employees via the System Settings REST API"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Suppose HR notifies you that five people will be leaving at the end of the month. When you receive notice of a departure, you set the User to [Will be deleted in the future], and delete them after the departure date has passed. This article explains how to carry out these two stages with the REST API.<\/p>\n\n\n\n

The difference between deleting and using [Will be deleted in the future] comes down to two points: whether it can be undone, and whether in-progress Cases can still be processed.<\/strong> [Will be deleted in the future] can be undone by unchecking the box, and because the User remains, in-progress Cases can continue to be processed as they are. A deleted User cannot be restored under the same ID, and when a Case advances to a Step that references that User, execution may fail. In either case, Apps that reference that User, for example in the Step Assignee settings, will show an App Settings Error.<\/p>\n\n\n\n

Between setting [Will be deleted in the future] and deletion, ask the App Administrator to fix the App settings, and hand over the tasks the User holds. The on-screen procedure is explained in How to Safely Delete Users Without Affecting Apps<\/a>.<\/p>\n\n\n\n

Both setting [Will be deleted in the future] and deleting can be done for each User from [System Settings] > [User List]. The REST API is worth using when this work is repeated every month. If you set things up so that the CSV of departing employees sent from the HR system can be used as is, then from the next time you only need to swap the CSV and run it.<\/p>\n\n\n\n

The code examples are in Python 3 and use the Requests package to send HTTP requests. They are split into two scripts, one that sets [Will be deleted in the future] and one that actually deletes, and both are written following the “Preparing to Call the API” code. “Complete Code” at the end gathers each of the two scripts together.<\/p>\n\n\n\n

Preparing the CSV<\/h3>\n\n\n\n

The CSV of departing employees only needs an email address column. Prepare it in the following form and save it as leavers.csv<\/code>.<\/p>\n\n\n\n

email\ndylan.thomas@example.com\nemily.dickinson@example.com<\/code><\/pre><\/div>\n\n\n\n
To find a User with the API, use the email address, because User names can be duplicated when two people share the same name.<\/p>\n\n\n\n
This CSV is used both when setting [Will be deleted in the future] and when deleting.<\/strong> Prepare it when you receive notice of the departure, and once the departure date has passed, use the same one again.<\/p>\n\n\n\n
Preparing to Call the API<\/h3>\n\n\n\n
The executing User needs User Manager authorization and permission for API access via Basic authentication.<\/strong> The setup steps and how to look up the API password are the same as in “Preparing to Call the API” in “Reflecting Hires and Transfers with the System Settings REST API.”<\/p>\n\n\n\n
Prepare the connection target and credentials as follows.<\/p>\n\n\n\n
import csv\nimport requests\nfrom requests.auth import HTTPBasicAuth\n\nBASE = 'https:\/\/example.questetra.net'\nAUTH = HTTPBasicAuth('admin@example.com', '{API Password}')\n<\/code><\/pre><\/div>\n\n\n\n
Route API calls through the following functions.<\/strong> When a call fails, it prints the response body and then stops. How to read the response body is also explained in “Preparing to Call the API” in the same article.<\/p>\n\n\n\n
def check(r):\n    if not r.ok:\n        print(r.status_code, r.text)\n        r.raise_for_status()\n    return r\n\n\ndef call(method, path, **kwargs):\n    return check(requests.request(method, f'{BASE}{path}', auth=AUTH, **kwargs))\n<\/code><\/pre><\/div>\n\n\n\n
When Notified of a Departure: Setting [Will be deleted in the future]<\/h3>\n\n\n\n
Before running this, tell the App Administrator that App Settings Errors will appear.<\/strong> As soon as a User is set to [Will be deleted in the future], Apps that reference that User will show an App Settings Error.<\/p>\n\n\n\n
[Will be deleted in the future] is set with deletedInFuture<\/code> of \/API\/UGA\/Quser\/update<\/code>. Because this API requires a User ID, look up the ID from the email address and then update.<\/p>\n\n\n\n
with open('leavers.csv', encoding='utf-8') as f:\n    for row in csv.DictReader(f):\n        found = requests.get(f'{BASE}\/API\/User\/Quser\/find', auth=AUTH,\n                             params={'email': row['email']})\n        if found.status_code != 400:\n            check(found)\n        if not found.ok:\n            print(row['email'], 'Not found')\n            continue\n        call('POST', '\/API\/UGA\/Quser\/update',\n             data={'id': found.json()['quser']['id'], 'deletedInFuture': 'true'})\n        print(row['email'], 'Set to Will be deleted in the future')\n<\/code><\/pre><\/div>\n\n\n\n
find<\/code> returns 400 for an unregistered email address.<\/strong> Only that specific case is treated as “not found,” and other errors such as authentication errors are stopped during the check<\/code> phase. This is why call<\/code> is not used here.<\/p>\n\n\n\n
update<\/code> does not change items that are not specified. Here only deletedInFuture<\/code> is passed, so the User name, email address, and Organization remain as they are.<\/p>\n\n\n\n
After the Departure Date: Deleting from the CSV<\/h3>\n\n\n\n
Deletion is also performed from the same CSV used when setting [Will be deleted in the future].<\/strong> The workflow platform does not hold departure dates. If you narrow the list by [Will be deleted in the future] and delete, you will also delete people whose departure date has not yet arrived, and Users that another person set to [Will be deleted in the future] for a different reason. Using that month’s CSV of departing employees keeps you from targeting the wrong Users.<\/p>\n\n\n\n
with open('leavers.csv', encoding='utf-8') as f:\n    for row in csv.DictReader(f):\n        found = requests.get(f'{BASE}\/API\/User\/Quser\/find', auth=AUTH,\n                             params={'email': row['email']})\n        if found.status_code != 400:\n            check(found)\n        if not found.ok:\n            print(row['email'], 'Not found')\n            continue\n        quser = found.json()['quser']\n        if not quser['deletedInFuture']:\n            print(row['email'], 'Not set to Will be deleted in the future')\n            continue\n        call('POST', '\/API\/UGA\/Quser\/delete', data={'id': quser['id']})\n        print(row['email'], 'Deleted')\n<\/code><\/pre><\/div>\n\n\n\n
A deleted User cannot be restored.<\/strong> Run this only after the App settings have been fixed and the remaining tasks have been handed over.<\/p>\n\n\n\n
Users who are not set to [Will be deleted in the future] are not deleted, but are printed out instead.<\/strong> This is because people who skipped the [Will be deleted in the future] step, or whose setting was once canceled, may remain in the CSV.<\/p>\n\n\n\n
Checking for Leftover Deletions<\/h3>\n\n\n\n
Users remaining as [Will be deleted in the future] can be checked in a list filtered by deletedInFuture<\/code>. The API that returns lists has an upper limit on the number of items returned in a single call. Specify the number per call with limit<\/code>, shift start<\/code> each time, and repeat until the number returned is less than limit<\/code>.<\/p>\n\n\n\n
LIMIT = 10\nstart = 0\nwhile True:\n    r = call('GET', '\/API\/User\/Quser\/list',\n             params={'deletedInFuture': 'true', 'start': start, 'limit': LIMIT})\n    qusers = r.json()['qusers']\n    for u in qusers:\n        print(u['id'], u['name'], u['email'])\n    if len(qusers) < LIMIT:\n        break\n    start += LIMIT\n<\/code><\/pre><\/div>\n\n\n\n
This list includes people whose departure date has not yet arrived, as well as Users that another person set to [Will be deleted in the future] for a different reason. You cannot tell from this list whether a User is OK to delete.<\/strong> Use it to cross-check against the CSV of departing employees and see whether anything was left undeleted.<\/p>\n\n\n\n
Complete Code<\/h3>\n\n\n\n
This is the script that sets [Will be deleted in the future]. Before running it, read “How to Proceed with Execution” below.<\/p>\n\n\n\n
import csv\nimport requests\nfrom requests.auth import HTTPBasicAuth\n\nBASE = 'https:\/\/example.questetra.net'\nAUTH = HTTPBasicAuth('admin@example.com', '{API Password}')\n\n\ndef check(r):\n    if not r.ok:\n        print(r.status_code, r.text)\n        r.raise_for_status()\n    return r\n\n\ndef call(method, path, **kwargs):\n    return check(requests.request(method, f'{BASE}{path}', auth=AUTH, **kwargs))\n\n\nwith open('leavers.csv', encoding='utf-8') as f:\n    for row in csv.DictReader(f):\n        found = requests.get(f'{BASE}\/API\/User\/Quser\/find', auth=AUTH,\n                             params={'email': row['email']})\n        if found.status_code != 400:\n            check(found)\n        if not found.ok:\n            print(row['email'], 'Not found')\n            continue\n        call('POST', '\/API\/UGA\/Quser\/update',\n             data={'id': found.json()['quser']['id'], 'deletedInFuture': 'true'})\n        print(row['email'], 'Set to Will be deleted in the future')\n<\/code><\/pre><\/div>\n\n\n\n
This is the script that deletes.<\/p>\n\n\n\n
import csv\nimport requests\nfrom requests.auth import HTTPBasicAuth\n\nBASE = 'https:\/\/example.questetra.net'\nAUTH = HTTPBasicAuth('admin@example.com', '{API Password}')\n\n\ndef check(r):\n    if not r.ok:\n        print(r.status_code, r.text)\n        r.raise_for_status()\n    return r\n\n\ndef call(method, path, **kwargs):\n    return check(requests.request(method, f'{BASE}{path}', auth=AUTH, **kwargs))\n\n\nwith open('leavers.csv', encoding='utf-8') as f:\n    for row in csv.DictReader(f):\n        found = requests.get(f'{BASE}\/API\/User\/Quser\/find', auth=AUTH,\n                             params={'email': row['email']})\n        if found.status_code != 400:\n            check(found)\n        if not found.ok:\n            print(row['email'], 'Not found')\n            continue\n        quser = found.json()['quser']\n        if not quser['deletedInFuture']:\n            print(row['email'], 'Not set to Will be deleted in the future')\n            continue\n        call('POST', '\/API\/UGA\/Quser\/delete', data={'id': quser['id']})\n        print(row['email'], 'Deleted')\n<\/code><\/pre><\/div>\n\n\n\n
How to Proceed with Execution<\/h3>\n\n\n\n
First, run the script with a CSV containing only one row, and confirm in [System Settings] > [User List] that the User has been set to [Will be deleted in the future].<\/strong> POST APIs rewrite the workflow platform’s data on the spot. Once you have confirmed this, run the remaining rows.<\/p>\n\n\n\n
Try the deletion script with a one-row CSV as well. Because deletion cannot be undone, confirm that this one person’s departure date has passed, and that the App settings fixes and task handover are complete, before running it.<\/strong><\/p>\n\n\n\n
Related Pages<\/h3>\n\n\n\n