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.:
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.