diff --git a/docs/usage/administration/admin_api/README.md b/docs/usage/administration/admin_api/README.md
deleted file mode 100644
index f11e0b19a6..0000000000
--- a/docs/usage/administration/admin_api/README.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# The Admin API
-
-## Authenticate 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.)
-
-An existing user can be marked as a server admin by updating the database directly.
-
-Check your [database settings](config_documentation.md#database) in the configuration file, connect to the correct database using either `psql [database name]` (if using PostgreSQL) or `sqlite3 path/to/your/database.db` (if using SQLite) and elevate the user `@foo:bar.com` to administrator.
-```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`
-command. This is a script that is distributed as part of synapse. It is possibly
-already on your `$PATH` depending on how Synapse was installed.
-
-Finding your user's `access_token` is client-dependent, but will usually be shown in the client's settings.
-
-## Making an Admin API request
-For security reasons, we [recommend](reverse_proxy.md#synapse-administration-endpoints)
-that the Admin API (`/_synapse/admin/...`) should be hidden from public view using a
-reverse proxy. This means you should typically query the Admin API from a terminal on
-the machine which runs Synapse.
-
-Once you have your `access_token`, you will need to authenticate each request to an Admin API endpoint by
-providing the token as either a query parameter or a request header. To add it as a request header in cURL:
-
-```sh
-curl --header "Authorization: Bearer <access_token>" <the_rest_of_your_API_request>
-```
-
-For example, suppose we want to
-[query the account](user_admin_api.md#query-user-account) of the user
-`@foo:bar.com`. We need an admin access token (e.g.
-`syt_AjfVef2_L33JNpafeif_0feKJfeaf0CQpoZk`), and we need to know which port
-Synapse's [`client` listener](config_documentation.md#listeners) is listening
-on (e.g. `8008`). Then we can use the following command to request the account
-information from the Admin API.
-
-```sh
-curl --header "Authorization: Bearer syt_AjfVef2_L33JNpafeif_0feKJfeaf0CQpoZk" -X GET http://127.0.0.1:8008/_synapse/admin/v2/users/@foo:bar.com
-```
-
-For more details on access tokens in Matrix, please refer to the complete
-[matrix spec documentation](https://matrix.org/docs/spec/client_server/r0.6.1#using-access-tokens).
diff --git a/docs/usage/administration/admin_api/background_updates.md b/docs/usage/administration/admin_api/background_updates.md
deleted file mode 100644
index 3cd0201b69..0000000000
--- a/docs/usage/administration/admin_api/background_updates.md
+++ /dev/null
@@ -1,109 +0,0 @@
-# Background Updates API
-
-This API allows a server administrator to manage the background updates being
-run against the database.
-
-## Status
-
-This API gets the current status of the background updates.
-
-
-The API is:
-
-```
-GET /_synapse/admin/v1/background_updates/status
-```
-
-Returning:
-
-```json
-{
- "enabled": true,
- "current_updates": {
- "<db_name>": {
- "name": "<background_update_name>",
- "total_item_count": 50,
- "total_duration_ms": 10000.0,
- "average_items_per_ms": 2.2,
- },
- }
-}
-```
-
-`enabled` whether the background updates are enabled or disabled.
-
-`db_name` the database name (usually Synapse is configured with a single database named 'master').
-
-For each update:
-
-`name` the name of the update.
-`total_item_count` total number of "items" processed (the meaning of 'items' depends on the update in question).
-`total_duration_ms` how long the background process has been running, not including time spent sleeping.
-`average_items_per_ms` how many items are processed per millisecond based on an exponential average.
-
-
-## Enabled
-
-This API allow pausing background updates.
-
-Background updates should *not* be paused for significant periods of time, as
-this can affect the performance of Synapse.
-
-*Note*: This won't persist over restarts.
-
-*Note*: This won't cancel any update query that is currently running. This is
-usually fine since most queries are short lived, except for `CREATE INDEX`
-background updates which won't be cancelled once started.
-
-
-The API is:
-
-```
-POST /_synapse/admin/v1/background_updates/enabled
-```
-
-with the following body:
-
-```json
-{
- "enabled": false
-}
-```
-
-`enabled` sets whether the background updates are enabled or disabled.
-
-The API returns the `enabled` param.
-
-```json
-{
- "enabled": false
-}
-```
-
-There is also a `GET` version which returns the `enabled` state.
-
-
-## Run
-
-This API schedules a specific background update to run. The job starts immediately after calling the API.
-
-
-The API is:
-
-```
-POST /_synapse/admin/v1/background_updates/start_job
-```
-
-with the following body:
-
-```json
-{
- "job_name": "populate_stats_process_rooms"
-}
-```
-
-The following JSON body parameters are available:
-
-- `job_name` - A string which job to run. Valid values are:
- - `populate_stats_process_rooms` - Recalculate the stats for all rooms.
- - `regenerate_directory` - Recalculate the [user directory](../../configuration/user_directory.md) if it is stale or out of sync.
diff --git a/docs/usage/administration/admin_api/federation.md b/docs/usage/administration/admin_api/federation.md
deleted file mode 100644
index 60cbc5265e..0000000000
--- a/docs/usage/administration/admin_api/federation.md
+++ /dev/null
@@ -1,212 +0,0 @@
-# Federation API
-
-This API allows a server administrator to manage Synapse's federation with other homeservers.
-
-Note: This API is new, experimental and "subject to change".
-
-## List of destinations
-
-This API gets the current destination retry timing info for all remote servers.
-
-The list contains all the servers with which the server federates,
-regardless of whether an error occurred or not.
-If an error occurs, it may take up to 20 minutes for the error to be displayed here,
-as a complete retry must have failed.
-
-The API is:
-
-A standard request with no filtering:
-
-```
-GET /_synapse/admin/v1/federation/destinations
-```
-
-A response body like the following is returned:
-
-```json
-{
- "destinations":[
- {
- "destination": "matrix.org",
- "retry_last_ts": 1557332397936,
- "retry_interval": 3000000,
- "failure_ts": 1557329397936,
- "last_successful_stream_ordering": null
- }
- ],
- "total": 1
-}
-```
-
-To paginate, check for `next_token` and if present, call the endpoint again
-with `from` set to the value of `next_token`. This will return a new page.
-
-If the endpoint does not return a `next_token` then there are no more destinations
-to paginate through.
-
-**Parameters**
-
-The following query parameters are available:
-
-- `from` - Offset in the returned list. Defaults to `0`.
-- `limit` - Maximum amount of destinations to return. Defaults to `100`.
-- `order_by` - The method in which to sort the returned list of destinations.
- Valid values are:
- - `destination` - Destinations are ordered alphabetically by remote server name.
- This is the default.
- - `retry_last_ts` - Destinations are ordered by time of last retry attempt in ms.
- - `retry_interval` - Destinations are ordered by how long until next retry in ms.
- - `failure_ts` - Destinations are ordered by when the server started failing in ms.
- - `last_successful_stream_ordering` - Destinations are ordered by the stream ordering
- of the most recent successfully-sent PDU.
-- `dir` - Direction of room order. Either `f` for forwards or `b` for backwards. Setting
- this value to `b` will reverse the above sort order. Defaults to `f`.
-
-*Caution:* The database only has an index on the column `destination`.
-This means that if a different sort order is used,
-this can cause a large load on the database, especially for large environments.
-
-**Response**
-
-The following fields are returned in the JSON response body:
-
-- `destinations` - An array of objects, each containing information about a destination.
- Destination objects contain the following fields:
- - `destination` - string - Name of the remote server to federate.
- - `retry_last_ts` - integer - The last time Synapse tried and failed to reach the
- remote server, in ms. This is `0` if the last attempt to communicate with the
- remote server was successful.
- - `retry_interval` - integer - How long since the last time Synapse tried to reach
- the remote server before trying again, in ms. This is `0` if no further retrying occuring.
- - `failure_ts` - nullable integer - The first time Synapse tried and failed to reach the
- remote server, in ms. This is `null` if communication with the remote server has never failed.
- - `last_successful_stream_ordering` - nullable integer - The stream ordering of the most
- recent successfully-sent [PDU](understanding_synapse_through_grafana_graphs.md#federation)
- to this destination, or `null` if this information has not been tracked yet.
-- `next_token`: string representing a positive integer - Indication for pagination. See above.
-- `total` - integer - Total number of destinations.
-
-## Destination Details API
-
-This API gets the retry timing info for a specific remote server.
-
-The API is:
-
-```
-GET /_synapse/admin/v1/federation/destinations/<destination>
-```
-
-A response body like the following is returned:
-
-```json
-{
- "destination": "matrix.org",
- "retry_last_ts": 1557332397936,
- "retry_interval": 3000000,
- "failure_ts": 1557329397936,
- "last_successful_stream_ordering": null
-}
-```
-
-**Parameters**
-
-The following parameters should be set in the URL:
-
-- `destination` - Name of the remote server.
-
-**Response**
-
-The response fields are the same like in the `destinations` array in
-[List of destinations](#list-of-destinations) response.
-
-## Destination rooms
-
-This API gets the rooms that federate with a specific remote server.
-
-The API is:
-
-```
-GET /_synapse/admin/v1/federation/destinations/<destination>/rooms
-```
-
-A response body like the following is returned:
-
-```json
-{
- "rooms":[
- {
- "room_id": "!OGEhHVWSdvArJzumhm:matrix.org",
- "stream_ordering": 8326
- },
- {
- "room_id": "!xYvNcQPhnkrdUmYczI:matrix.org",
- "stream_ordering": 93534
- }
- ],
- "total": 2
-}
-```
-
-To paginate, check for `next_token` and if present, call the endpoint again
-with `from` set to the value of `next_token`. This will return a new page.
-
-If the endpoint does not return a `next_token` then there are no more destinations
-to paginate through.
-
-**Parameters**
-
-The following parameters should be set in the URL:
-
-- `destination` - Name of the remote server.
-
-The following query parameters are available:
-
-- `from` - Offset in the returned list. Defaults to `0`.
-- `limit` - Maximum amount of destinations to return. Defaults to `100`.
-- `dir` - Direction of room order by `room_id`. Either `f` for forwards or `b` for
- backwards. Defaults to `f`.
-
-**Response**
-
-The following fields are returned in the JSON response body:
-
-- `rooms` - An array of objects, each containing information about a room.
- Room objects contain the following fields:
- - `room_id` - string - The ID of the room.
- - `stream_ordering` - integer - The stream ordering of the most recent
- successfully-sent [PDU](understanding_synapse_through_grafana_graphs.md#federation)
- to this destination in this room.
-- `next_token`: string representing a positive integer - Indication for pagination. See above.
-- `total` - integer - Total number of destinations.
-
-## Reset connection timeout
-
-Synapse makes federation requests to other homeservers. If a federation request fails,
-Synapse will mark the destination homeserver as offline, preventing any future requests
-to that server for a "cooldown" period. This period grows over time if the server
-continues to fail its responses
-([exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff)).
-
-Admins can cancel the cooldown period with this API.
-
-This API resets the retry timing for a specific remote server and tries to connect to
-the remote server again. It does not wait for the next `retry_interval`.
-The connection must have previously run into an error and `retry_last_ts`
-([Destination Details API](#destination-details-api)) must not be equal to `0`.
-
-The connection attempt is carried out in the background and can take a while
-even if the API already returns the http status 200.
-
-The API is:
-
-```
-POST /_synapse/admin/v1/federation/destinations/<destination>/reset_connection
-
-{}
-```
-
-**Parameters**
-
-The following parameters should be set in the URL:
-
-- `destination` - Name of the remote server.
diff --git a/docs/usage/administration/admin_api/registration_tokens.md b/docs/usage/administration/admin_api/registration_tokens.md
deleted file mode 100644
index 90cbc21125..0000000000
--- a/docs/usage/administration/admin_api/registration_tokens.md
+++ /dev/null
@@ -1,296 +0,0 @@
-# Registration Tokens
-
-This API allows you to manage tokens which can be used to authenticate
-registration requests, as proposed in
-[MSC3231](https://github.com/matrix-org/matrix-doc/blob/main/proposals/3231-token-authenticated-registration.md)
-and stabilised in version 1.2 of the Matrix specification.
-To use it, you will need to enable the `registration_requires_token` config
-option, and authenticate by providing an `access_token` for a server admin:
-see [Admin API](../admin_api).
-
-
-## Registration token objects
-
-Most endpoints make use of JSON objects that contain details about tokens.
-These objects have the following fields:
-- `token`: The token which can be used to authenticate registration.
-- `uses_allowed`: The number of times the token can be used to complete a
- registration before it becomes invalid.
-- `pending`: The number of pending uses the token has. When someone uses
- the token to authenticate themselves, the pending counter is incremented
- so that the token is not used more than the permitted number of times.
- When the person completes registration the pending counter is decremented,
- and the completed counter is incremented.
-- `completed`: The number of times the token has been used to successfully
- complete a registration.
-- `expiry_time`: The latest time the token is valid. Given as the number of
- milliseconds since 1970-01-01 00:00:00 UTC (the start of the Unix epoch).
- To convert this into a human-readable form you can remove the milliseconds
- and use the `date` command. For example, `date -d '@1625394937'`.
-
-
-## List all tokens
-
-Lists all tokens and details about them. If the request is successful, the top
-level JSON object will have a `registration_tokens` key which is an array of
-registration token objects.
-
-```
-GET /_synapse/admin/v1/registration_tokens
-```
-
-Optional query parameters:
-- `valid`: `true` or `false`. If `true`, only valid tokens are returned.
- If `false`, only tokens that have expired or have had all uses exhausted are
- returned. If omitted, all tokens are returned regardless of validity.
-
-Example:
-
-```
-GET /_synapse/admin/v1/registration_tokens
-```
-```
-200 OK
-
-{
- "registration_tokens": [
- {
- "token": "abcd",
- "uses_allowed": 3,
- "pending": 0,
- "completed": 1,
- "expiry_time": null
- },
- {
- "token": "pqrs",
- "uses_allowed": 2,
- "pending": 1,
- "completed": 1,
- "expiry_time": null
- },
- {
- "token": "wxyz",
- "uses_allowed": null,
- "pending": 0,
- "completed": 9,
- "expiry_time": 1625394937000 // 2021-07-04 10:35:37 UTC
- }
- ]
-}
-```
-
-Example using the `valid` query parameter:
-
-```
-GET /_synapse/admin/v1/registration_tokens?valid=false
-```
-```
-200 OK
-
-{
- "registration_tokens": [
- {
- "token": "pqrs",
- "uses_allowed": 2,
- "pending": 1,
- "completed": 1,
- "expiry_time": null
- },
- {
- "token": "wxyz",
- "uses_allowed": null,
- "pending": 0,
- "completed": 9,
- "expiry_time": 1625394937000 // 2021-07-04 10:35:37 UTC
- }
- ]
-}
-```
-
-
-## Get one token
-
-Get details about a single token. If the request is successful, the response
-body will be a registration token object.
-
-```
-GET /_synapse/admin/v1/registration_tokens/<token>
-```
-
-Path parameters:
-- `token`: The registration token to return details of.
-
-Example:
-
-```
-GET /_synapse/admin/v1/registration_tokens/abcd
-```
-```
-200 OK
-
-{
- "token": "abcd",
- "uses_allowed": 3,
- "pending": 0,
- "completed": 1,
- "expiry_time": null
-}
-```
-
-
-## Create token
-
-Create a new registration token. If the request is successful, the newly created
-token will be returned as a registration token object in the response body.
-
-```
-POST /_synapse/admin/v1/registration_tokens/new
-```
-
-The request body must be a JSON object and can contain the following fields:
-- `token`: The registration token. A string of no more than 64 characters that
- consists only of characters matched by the regex `[A-Za-z0-9._~-]`.
- Default: randomly generated.
-- `uses_allowed`: The integer number of times the token can be used to complete
- a registration before it becomes invalid.
- Default: `null` (unlimited uses).
-- `expiry_time`: The latest time the token is valid. Given as the number of
- milliseconds since 1970-01-01 00:00:00 UTC (the start of the Unix epoch).
- You could use, for example, `date '+%s000' -d 'tomorrow'`.
- Default: `null` (token does not expire).
-- `length`: The length of the token randomly generated if `token` is not
- specified. Must be between 1 and 64 inclusive. Default: `16`.
-
-If a field is omitted the default is used.
-
-Example using defaults:
-
-```
-POST /_synapse/admin/v1/registration_tokens/new
-
-{}
-```
-```
-200 OK
-
-{
- "token": "0M-9jbkf2t_Tgiw1",
- "uses_allowed": null,
- "pending": 0,
- "completed": 0,
- "expiry_time": null
-}
-```
-
-Example specifying some fields:
-
-```
-POST /_synapse/admin/v1/registration_tokens/new
-
-{
- "token": "defg",
- "uses_allowed": 1
-}
-```
-```
-200 OK
-
-{
- "token": "defg",
- "uses_allowed": 1,
- "pending": 0,
- "completed": 0,
- "expiry_time": null
-}
-```
-
-
-## Update token
-
-Update the number of allowed uses or expiry time of a token. If the request is
-successful, the updated token will be returned as a registration token object
-in the response body.
-
-```
-PUT /_synapse/admin/v1/registration_tokens/<token>
-```
-
-Path parameters:
-- `token`: The registration token to update.
-
-The request body must be a JSON object and can contain the following fields:
-- `uses_allowed`: The integer number of times the token can be used to complete
- a registration before it becomes invalid. By setting `uses_allowed` to `0`
- the token can be easily made invalid without deleting it.
- If `null` the token will have an unlimited number of uses.
-- `expiry_time`: The latest time the token is valid. Given as the number of
- milliseconds since 1970-01-01 00:00:00 UTC (the start of the Unix epoch).
- If `null` the token will not expire.
-
-If a field is omitted its value is not modified.
-
-Example:
-
-```
-PUT /_synapse/admin/v1/registration_tokens/defg
-
-{
- "expiry_time": 4781243146000 // 2121-07-06 11:05:46 UTC
-}
-```
-```
-200 OK
-
-{
- "token": "defg",
- "uses_allowed": 1,
- "pending": 0,
- "completed": 0,
- "expiry_time": 4781243146000
-}
-```
-
-
-## Delete token
-
-Delete a registration token. If the request is successful, the response body
-will be an empty JSON object.
-
-```
-DELETE /_synapse/admin/v1/registration_tokens/<token>
-```
-
-Path parameters:
-- `token`: The registration token to delete.
-
-Example:
-
-```
-DELETE /_synapse/admin/v1/registration_tokens/wxyz
-```
-```
-200 OK
-
-{}
-```
-
-
-## Errors
-
-If a request fails a "standard error response" will be returned as defined in
-the [Matrix Client-Server API specification](https://matrix.org/docs/spec/client_server/r0.6.1#api-standards).
-
-For example, if the token specified in a path parameter does not exist a
-`404 Not Found` error will be returned.
-
-```
-GET /_synapse/admin/v1/registration_tokens/1234
-```
-```
-404 Not Found
-
-{
- "errcode": "M_NOT_FOUND",
- "error": "No such registration token: 1234"
-}
-```
diff --git a/docs/usage/configuration/config_documentation.md b/docs/usage/configuration/config_documentation.md
index 20ed41e16a..5b66be0918 100644
--- a/docs/usage/configuration/config_documentation.md
+++ b/docs/usage/configuration/config_documentation.md
@@ -1702,9 +1702,9 @@ and the original media will be removed. If either of these options are unset,
then media of that type will not be purged.
Local or cached remote media that has been
-[quarantined](../../admin_api/media_admin_api.md#quarantining-media-in-a-room)
+[quarantined](../../administration/admin_api/media_admin_api.md#quarantining-media-in-a-room)
will not be deleted. Similarly, local media that has been marked as
-[protected from quarantine](../../admin_api/media_admin_api.md#protecting-media-from-being-quarantined)
+[protected from quarantine](../../administration/admin_api/media_admin_api.md#protecting-media-from-being-quarantined)
will not be deleted.
Example configuration:
@@ -2068,7 +2068,7 @@ enable_3pid_lookup: false
### `registration_requires_token`
Require users to submit a token during registration.
-Tokens can be managed using the admin [API](../administration/admin_api/registration_tokens.md).
+Tokens can be managed using the admin [API](../../administration/admin_api/registration_tokens.md).
Disabling this option will not delete any tokens previously generated.
Defaults to `false`. Set to `true` to enable.
@@ -3425,7 +3425,7 @@ This option has the following sub-options:
These indexes are built the first time Synapse starts; admins can
manually trigger a rebuild via the API following the instructions
- [for running background updates](../administration/admin_api/background_updates.md#run),
+ [for running background updates](../../administration/admin_api/background_updates.md#run),
set to true to return search results containing all known users, even if that
user does not share a room with the requester.
* `prefer_local_users`: Defines whether to prefer local users in search query results.
diff --git a/docs/usage/configuration/user_directory.md b/docs/usage/configuration/user_directory.md
index 31da9fd4b3..5fa6079ba7 100644
--- a/docs/usage/configuration/user_directory.md
+++ b/docs/usage/configuration/user_directory.md
@@ -7,7 +7,7 @@ who are present in a publicly viewable room present on the server.
The directory info is stored in various tables, which can (typically after
DB corruption) get stale or out of sync. If this happens, for now the
-solution to fix it is to use the [admin API](../administration/admin_api/background_updates.md#run)
+solution to fix it is to use the [admin API](../../administration/admin_api/background_updates.md#run)
and execute the job `regenerate_directory`. This should then start a background task to
flush the current tables and regenerate the directory.
|
