Database housekeeping is the task every Automic administrator knows they should run regularly and quietly keeps postponing — until execution data, old reports and system messages have bloated the AE database. For years, Automic database maintenance meant reaching for the local AE DB utilities or going to the database directly, which is exactly why it slid down the to-do list. In Automic V26 that friction is gone: you can archive, reorganize, delete and clean up operational data straight from the AWI Administration perspective and the AE REST API. This article is part of our Automic V26 enablement series, and it focuses on the REST API path — the walkthrough video below shows the same operations end to end.
What changed in Automic database maintenance in V26
In earlier releases, archiving, reorganizing and unloading the AE database was handled by the standalone AE DB utilities or by working against the database directly. Automic V26 brings these activities under governed, API-driven control: the same maintenance tasks are now exposed through the AE REST API and the AWI Administration perspective, so you no longer need local utility binaries or direct database credentials to run them.
Throughout, the data you are managing is what Automic calls operational data: system messages, execution data (formerly called statistics), reports and comments. Across the board, the AE REST API covers five operations: archive operational data, create revision reports, reorganize operational data, delete operational data, and empty the Recycle Bin.
The practical payoff is governance. Routing maintenance through the AE REST API means every archive, reorganization and deletion is an auditable, repeatable call rather than an ad hoc utility run on someone’s workstation — and it can be granted through a single privilege instead of database-level access. For regulated Automic estates, that traceability matters as much as the freed-up database space.
Privileges and configuration to set up first
Before you run any Automic database maintenance through the REST API, two things need to be in place: the right user privileges and the variables that control each operation.
- Privileges. The
DB_MAINTENANCEprivilege starts the archiving, reorganization and deletion processes. To download archive packages and revision reports you also needACCESS_METRICS_ENDPOINT, and to read or empty the Recycle Bin you needRECYCLE_BIN. - Configuration variables in Client 0. Archiving parameters live in
UC_UTILITY_ARCHIVE, reorganization parameters inUC_UTILITY_REORG, and deletion parameters inUC_UTILITY_DB_UNLOAD. For revision reports, object logging (OBJECT_AUDIT) must be enabled inUC_CLIENT_SETTINGS. - Output location. The archive or report package is written automatically to the directory you define in the Automation Engine INI file for on-premises systems, or in the
values.yamlfile for AAKE (containerized) environments. From there you transfer it wherever you need it.
With the privileges granted and the variables configured once, every subsequent run is a single API call. The walkthrough below shows these operations in the AWI and via the AE REST API — follow along, then use the reference calls in the second half of this guide.
The maintenance operations via the AE REST API
Each operation is triggered in Client 0 and can target a single client (target_client=100) or every client (target_client=ALL) — you cannot select an arbitrary subset. Most processes return a run_id that you use to fetch the resulting package.
Archiving operational data
Archiving collects system messages, execution data, reports and comments into a downloadable ZIP. You trigger it with a POST, then download the package with the returned run ID:
POST /ae/api/v1/0/system/clients/archive?target_client=100
→ { "run_id": 1007001 }
GET /ae/api/v1/0/system/clients/archive/1007001
→ (downloads the archive package)With a REST client such as Postman, use the Send and Download option; with cURL, add -o to write the file to disk. The same endpoint called with the reset method clears the archive flag.
Creating revision reports
Revision reports give you a chronological, audit-ready record of changes in a client — created objects, deletions, transports, user logons and more — which is what keeps a regulated environment compliant. You can scope a report by date range and by change type:
POST /ae/api/v1/0/system/clients/revisionreport?target_client=ALL
{
"from": "2026-01-01T00:00:00Z",
"to": "2026-03-31T00:00:00Z",
"types": ["CREATE", "DELETE", "OBJ_MOD", "USER", "TRNSPRT"]
}If types is omitted, all change categories are included. The report is downloaded with its run_id, exactly like an archive package.
Reorganizing operational data
Reorganize operational data marks aging records for deletion without removing them yet. The retention logic combines two settings: a reorganize older than threshold in days and a keep last count. For example, with reorganize older than set to 30 and keep last set to 5, the process keeps everything from the last 30 days plus the five most recent older records per object.
POST /ae/api/v1/0/system/clients/reorg?target_client=ALLDeleting operational data
Once records are marked, deleting operational data removes them permanently from the AE database. It is a single trigger per client or for all clients:
POST /ae/api/v1/0/system/clients/deletedata?target_client=ALLEmptying the Recycle Bin
Deleted objects move to the Recycle Bin rather than disappearing immediately. From Client 0 you can list a client’s bin contents and then empty it:
GET /ae/api/v1/0/recyclebin?target_client=100
DELETE /ae/api/v1/0/recyclebin?target_client=ALLObjects that still hold unarchived operational data are not deleted; they are returned in the response under failedObjects. The rule of thumb is simple: archive first, then empty.
Resetting archive and reorganization flags
If you need to re-run a cycle — for example, to archive records that were already flagged — the archive and reorganization endpoints accept a reset method that clears the corresponding flag. This lets you correct a mistimed run without touching the database, keeping the whole maintenance cycle inside the AE REST API.
Make Automic database maintenance a scheduled job, not a chore
Because every operation is now a plain REST call, the natural next step is to stop running them by hand. Wrap the archive → reorganize → delete sequence in a scheduled Automic workflow so the AE database is maintained on a predictable cadence — and include Client 0, which accumulates server and agent logs and is easy to forget. If you would rather call the endpoints from a script, the new Automic V26 Python integration lets you invoke them from a native Python job alongside your existing automation logic. Reliable Automic database maintenance is one of the least glamorous but most load-bearing parts of running V26 well.
A sensible pattern is to reorganize on a regular schedule, archive before deletion, and sweep the Recycle Bin once archiving has confirmed nothing is left unarchived. Tuning the retention thresholds to your data volume is where most of the value sits — aggressive enough to keep the database lean, conservative enough to satisfy your audit window.
This guide is part of our Automic V26 enablement series. If SAP is central to your landscape, the companion piece on SAP Agent Multiple System Support covers another V26 change worth reviewing before you upgrade. For the official specification, see Broadcom’s Automic V26 release overview and the 26.0 AE REST API database maintenance documentation.
Frequently asked questions
Which privileges do I need for Automic database maintenance via the REST API?
You need the DB_MAINTENANCE privilege to start archiving, reorganization and deletion. To download archive packages and revision reports you also need ACCESS_METRICS_ENDPOINT, and to read or empty the Recycle Bin you need the RECYCLE_BIN privilege.
Does this work on-premises as well as in containerized AAKE environments?
Yes. The operations are identical; only the output location differs. On-premises you set the package directory in the Automation Engine INI file, and in AAKE (container) environments you set it in the values.yaml file.
What does Automic count as operational data?
Operational data means system messages, execution data (formerly called statistics), reports and comments. These are the records that accumulate during daily operation and that maintenance is designed to archive, reorganize and remove.
Can I run maintenance for all clients at once?
Yes. From Client 0 you can target a single client with target_client=100 or every client with target_client=ALL. You cannot select an arbitrary subset of clients in a single call.
How do I download an archive package or a revision report?
Use the run_id returned when you trigger the process in a follow-up GET request. In Postman, use the Send and Download option; with cURL, add the -o flag to write the file to disk.
What is the difference between reorganizing and deleting?
Reorganizing marks aging operational data for deletion based on your retention settings but leaves it in the database. Deleting then removes the marked records permanently. Running reorganize first and delete second keeps you in control of what actually leaves the database.
Where is the archive or report package stored?
When you trigger the process, a background job collects the data into a ZIP file and writes it to the directory defined in the Automation Engine INI file (on-premises) or the values.yaml file (AAKE). You then download or transfer it from there.
Plan your V26 maintenance setup
Moving database maintenance to the REST API is a small change with an outsized payoff in audit-readiness and database health — but it is worth getting the privileges, retention thresholds and schedule right for your specific landscape. If you would like a second pair of eyes on your V26 setup, book a free consultation with the Tricise Automic team.
