summary refs log tree commit diff
path: root/docs/admin_api
diff options
context:
space:
mode:
authorTravis Ralston <travpc@gmail.com>2018-04-04 08:46:56 -0600
committerTravis Ralston <travpc@gmail.com>2018-04-04 08:46:56 -0600
commit88964b987e1d80d2dc9e81fc3ebc51afd9defbe1 (patch)
treec98c28e51a8d52a8878cf2d888a4a110a835d8a8 /docs/admin_api
parentDocument the additional routes for the event_creator worker (diff)
parentMerge pull request #3062 from matrix-org/revert-3053-speedup-mxid-check (diff)
downloadsynapse-88964b987e1d80d2dc9e81fc3ebc51afd9defbe1.tar.xz
Merge remote-tracking branch 'matrix-org/develop' into travis/new-worker-docs
Diffstat (limited to 'docs/admin_api')
-rw-r--r--docs/admin_api/purge_history_api.rst44
1 files changed, 40 insertions, 4 deletions
diff --git a/docs/admin_api/purge_history_api.rst b/docs/admin_api/purge_history_api.rst

index a3a17e9f9f..2da833c827 100644 --- a/docs/admin_api/purge_history_api.rst +++ b/docs/admin_api/purge_history_api.rst
@@ -8,20 +8,56 @@ 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 simply: +The API is: -``POST /_matrix/client/r0/admin/purge_history/<room_id>/<event_id>`` +``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). +deleted.) -To delete local events as well, set ``delete_local_events`` in the body: +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``.