Make the purge request return quickly, and allow scripts to poll for updates.
1.8 KiB
Purge History API
The purge history API allows server admins to purge historic events from their database, reclaiming disk space.
Depending on the amount of history being purged a call to the API may take several minutes or longer. During this period users will not be able to paginate further back in the room from the point being purged from.
The API is:
POST /_matrix/client/r0/admin/purge_history/<room_id>[/<event_id>]
including an access_token
of a server admin.
By default, events sent by local users are not deleted, as they may represent the only copies of this content in existence. (Events sent by remote users are deleted, and room state data before the cutoff is always removed).
To delete local events as well, set delete_local_events
in the body:
{
"delete_local_events": true
}
The caller must specify the point in the room to purge up to. This
can be specified by including an event_id in the URI, or by setting a
purge_up_to_event_id
or purge_up_to_ts
in the
request body. If an event id is given, that event (and others at the
same graph depth) will be retained. If purge_up_to_ts
is
given, it should be a timestamp since the unix epoch, in
milliseconds.
The API starts the purge running, and returns immediately with a JSON body with a purge id:
{
"purge_id": "<opaque id>"
}
Purge status query
It is possible to poll for updates on recent purges with a second API;
GET /_matrix/client/r0/admin/purge_history_status/<purge_id>
(again, with a suitable access_token
). This API returns
a JSON body like the following:
{
"status": "active"
}
The status will be one of active
, complete
,
or failed
.