Generated file. Do not edit endpoint rows by hand; regenerate with node scripts/generate-matrix-v119-spec-doc.mjs.
This lists every operation in the v1.19 OpenAPI document. It is a spec reference, not an implementation-status tracker: operations the server does not route are listed in docs/todos/capability-gaps.md.
Single-device GET, PUT and password-UIA DELETE extract deviceId from the
request path before the query separator. Unrelated query text does not rename
the selected device or alter its deletion/session revocation. Authentication
and the password-UIA requirement remain unchanged.
Backup-version DELETE also selects version from the path before ?.
Unrelated query text cannot turn a successful deletion into a no-op on the
intended version. SQLite regressions check deletion after reopening the store,
preservation of another version and repeated deletion; encryption and backed-up
session cascade are outside that regression's scope.
Implementation note (0.12.16, CSAZ-5): local public-room listings now require
explicit directory publication; a public join rule alone does not publish a
room. createRoom defaults to private directory visibility, and explicit
public visibility publishes it. The existing public-join listing filter is
retained. Directory publication is still in-memory, and POST authentication
has not yet been enforced; both remain tracked gaps, not completed fixes.
Implementation note (0.12.16, CSAZ-7): invite and knock summaries expose only
sender, type, state_key, and content. The disclosure policy permits the
seven room-summary types recommended in the stripped-state specification plus
the recipient's own membership, excluding other membership events, ACLs, power
levels, and custom private state. Local invitations retain their invitation-time
snapshot; historical and federated snapshots are re-pruned on client reads,
including sliding-sync invite responses. Matrix permits additional event types;
the restrictive allowlist is our policy (ADR-0088), not a protocol prohibition.
Refresh-enabled POST /_matrix/client/v3/login and POST /_matrix/client/v3/refresh
include expires_in_ms for positive configured access-token lifetimes. When
security.access_token_lifetime_ms is zero, both omit the optional field: its
absence means that the issued access token does not expire (Matrix v1.19).
Legacy login without refresh support is unchanged. These response semantics are
covered by tests/conformance/test_token_expiry_conformance.cpp; registration
expiry responses are outside that scenario's scope.
POST /_matrix/client/v3/publicRooms runs after the shared authentication and account-state gates, including remote lookups. Directory publication is durable and independent of join rules: a published invite-only room remains listed. Presence sync includes only peers sharing a current joined membership; PUT presence requires online, offline or unavailable and an optional string status_msg. The local 1024 UTF-8 byte status cap is resource policy (ADR-0098).
Application service ping, network directories and 3PID requestToken (conformance wave 3)¶
POST /_matrix/client/v1/appservice/{appserviceId}/ping requires an application service as_token whose appservice is the one named in the path (403 M_FORBIDDEN for a user's token, another appservice's token or an unknown id; 401 with no token). It calls POST /_matrix/app/v1/ping on the registered url with the registration's hs_token and the optional transaction_id, copied as given, the empty string included (a non-string is 400 M_BAD_JSON), and answers 200 {"duration_ms": N}, 400 M_URL_NOT_SET, 502 M_CONNECTION_FAILED, 502 M_BAD_STATUS carrying the appservice's status and a body cut to 1024 bytes of well-formed UTF-8, or 504 M_CONNECTION_TIMEOUT. It is not rate limited for a verified appservice, holds a client-outbound slot (429 M_LIMIT_EXCEEDED when none is free), and releases runtime.mutex for the call.
PUT /_matrix/client/v3/directory/list/appservice/{networkId}/{roomId} takes {"visibility": "public" | "private"} from an as_token and persists the room in the directory of that network (ADR-0192): networkId must be a protocol the registration declares (404 M_NOT_FOUND), the room must exist (404) and the appservice must have an interest in it (403 M_FORBIDDEN); a user's token is 403. POST /publicRooms lists the homeserver's own directory by default, one network's rooms for third_party_instance_id (the instance_id from GET /thirdparty/protocol/{protocol}, <registration id>:<protocol>:<index>), and both together for include_all_networks: true. Naming both is 400 M_INVALID_PARAM; a wrong type for either is 400 M_BAD_JSON; an id that names no network lists nothing. A ?server= lookup forwards both fields to the remote server.
The four requestToken endpoints (/register/{email,msisdn}/requestToken, /account/3pid/{email,msisdn}/requestToken) forward the client's send_attempt to the identity server, and every route that forwards an id_access_token (those, /account/3pid/bind, /account/3pid and the 3PID form of /rooms/{roomId}/invite) answers 400 M_INVALID_PARAM for one that is not printable ASCII without spaces of at most 4096 bytes.
POST /_matrix/client/v3/keys/upload answers 400 M_TOO_LARGE and stores nothing (no device, one-time or fallback keys) when the request would leave a device holding more than server.client_api.max_one_time_keys_per_device one-time keys; key IDs already held are not counted twice. A device keeps one fallback key per algorithm: a newly uploaded fallback key replaces the previous key of that algorithm. POST /_matrix/client/v3/keys/signatures/upload answers 400 M_TOO_LARGE and stores nothing when it would take the signer past server.client_api.max_key_signatures_per_user distinct (target user, target key) signatures. POST /_matrix/client/v3/user/{userId}/filter returns the existing filter_id for a definition identical to a stored one after JSON canonicalisation, and otherwise answers 400 M_TOO_LARGE once the user holds server.client_api.max_filters_per_user filters. Over-cap requests are refused, never satisfied by evicting stored rows. See operator budgets.
The client-server runtime applies server.client_api policy to sync room/timeline counts, message/search/context work and pages, notifications/relations/threads/public-room/hierarchy listings and transient session cardinality. Sliding-sync parsing receives the same configured policy for timeline/subscription/state-pair caps. Client-requested limits remain upper bounds; increasing a server maximum does not change a client's requested timeline size or bypass history visibility, ignore-list or accepted-event filtering. See operator budgets for defaults and ranges. Runtime policies require restart.
Room account data (GET/PUT /user/{userId}/rooms/{roomId}/account_data/{type}) is routed. Both account-data PUTs require a JSON object body (400 M_NOT_JSON / M_BAD_JSON) and refuse the server-managed m.fully_read and m.push_rules with 405 M_BAD_JSON. A room PUT needs a membership row in the room and stops new types at server.client_api.max_room_account_data_per_room (ADR-0197). POST /register without username gets a generated localpart (ADR-0198). PUT /rooms/{roomId}/typing/{userId} requires a boolean typing, and typing expires after its timeout, at most 120 s (ADR-0199). POST /search covers rooms the user has left, up to the point they left.