123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263 |
- 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.)
- Room state data (such as joins, leaves, topic) is always preserved.
- To delete local message events as well, set ``delete_local_events`` in the body:
- .. code:: json
- {
- "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:
- .. code:: json
- {
- "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:
- .. code:: json
- {
- "status": "active"
- }
- The status will be one of ``active``, ``complete``, or ``failed``.
|