forked from MirrorHub/synapse
b60bb28bbc
This could arguably replace the existing admin API for `/members`, however that is out of scope of this change. This sort of endpoint is ideal for moderation use cases as well as other applications, such as needing to retrieve various bits of information about a room to perform a task (like syncing power levels between two places). This endpoint exposes nothing more than an admin would be able to access with a `select *` query on their database. |
||
|---|---|---|
| .. | ||
| account_validity.rst | ||
| delete_group.md | ||
| event_reports.md | ||
| media_admin_api.md | ||
| purge_history_api.rst | ||
| purge_room.md | ||
| README.rst | ||
| register_api.rst | ||
| room_membership.md | ||
| rooms.md | ||
| server_notices.md | ||
| shutdown_room.md | ||
| statistics.md | ||
| user_admin_api.rst | ||
| version_api.rst | ||
Admin APIs
==========
This directory includes documentation for the various synapse specific admin
APIs available.
Authenticating as a server admin
--------------------------------
Many of the API calls in the admin api will require an `access_token` for a
server admin. (Note that a server admin is distinct from a room admin.)
A user can be marked as a server admin by updating the database directly, e.g.:
.. code-block:: sql
UPDATE users SET admin = 1 WHERE name = '@foo:bar.com';
A new server admin user can also be created using the
``register_new_matrix_user`` script.
Finding your user's `access_token` is client-dependent, but will usually be shown in the client's settings.
Once you have your `access_token`, to include it in a request, the best option is to add the token to a request header:
``curl --header "Authorization: Bearer <access_token>" <the_rest_of_your_API_request>``
Fore more details, please refer to the complete `matrix spec documentation <https://matrix.org/docs/spec/client_server/r0.5.0#using-access-tokens>`_.