2016-07-28 07:56:09 -06:00
|
|
|
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.
|
|
|
|
|
2018-03-01 16:20:54 -07:00
|
|
|
The API is:
|
2016-07-28 07:56:09 -06:00
|
|
|
|
2018-03-01 16:20:54 -07:00
|
|
|
``POST /_matrix/client/r0/admin/purge_history/<room_id>[/<event_id>]``
|
2016-07-28 07:56:09 -06:00
|
|
|
|
|
|
|
including an ``access_token`` of a server admin.
|
2018-02-08 11:44:52 -07:00
|
|
|
|
|
|
|
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:
|
|
|
|
|
|
|
|
.. code:: json
|
|
|
|
|
|
|
|
{
|
2018-02-13 06:04:41 -07:00
|
|
|
"delete_local_events": true
|
2018-02-08 11:44:52 -07:00
|
|
|
}
|
2018-03-01 16:20:54 -07:00
|
|
|
|
|
|
|
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.
|