@@ -3348,8 +3348,8 @@ room at the start of the returned timeline. The response also includes a
33483348` next_batch ` field, which should be used as the value of the ` since `
33493349parameter in the next call to ` /sync ` . Finally, the response includes,
33503350for each room, a ` prev_batch ` field, which can be passed as a ` from ` /` to `
3351- parameter to the [ ` /rooms/<room_id> /messages ` ] ( /client-server-api/ #get_matrixclientv3roomsroomidmessages) API to retrieve earlier
3352- messages.
3351+ parameter to the [ ` /rooms/{roomId} /messages ` ] ( #get_matrixclientv3roomsroomidmessages )
3352+ API to retrieve earlier messages.
33533353
33543354For example, a ` /sync ` request might return a range of four events
33553355` E2 ` , ` E3 ` , ` E4 ` and ` E5 ` within a given room, omitting two prior events
@@ -3368,7 +3368,8 @@ response to the previous call as the `since` parameter. The client
33683368should also pass a ` timeout ` parameter. The server will then hold open
33693369the HTTP connection for a short period of time waiting for new events,
33703370returning early if an event occurs. Only the ` /sync ` API (and the
3371- deprecated ` /events ` API) support long-polling in this way.
3371+ deprecated [ ` /events ` ] ( #get_matrixclientv3events ) API) support
3372+ long-polling in this way.
33723373
33733374Continuing the example above, an incremental sync might report
33743375a single new event ` E6 ` . The response can be visualised as:
@@ -3388,7 +3389,7 @@ containing only the most recent message events. A state "delta" is also
33883389returned, summarising any state changes in the omitted part of the
33893390timeline. The client may therefore end up with "gaps" in its knowledge
33903391of the message timeline. The client can fill these gaps using the
3391- [ ` /rooms/<room_id> /messages ` ] ( /client-server-api/ #get_matrixclientv3roomsroomidmessages) API.
3392+ [ ` /rooms/{roomId} /messages ` ] ( #get_matrixclientv3roomsroomidmessages ) API.
33923393
33933394Continuing our example, suppose we make a third ` /sync ` request asking for
33943395events since the last sync, by passing the ` next_batch ` token ` x-y-z ` as
@@ -3411,7 +3412,7 @@ The limited response includes a state delta which describes how the state
34113412of the room changes over the gap. This delta explains how to build the state
34123413prior to returned timeline (i.e. at ` E7 ` ) from the state the client knows
34133414(i.e. at ` E6 ` ). To close the gap, the client should make a request to
3414- [ ` /rooms/<room_id> /messages ` ] ( /client-server-api/ #get_matrixclientv3roomsroomidmessages)
3415+ [ ` /rooms/{roomId} /messages ` ] ( #get_matrixclientv3roomsroomidmessages )
34153416with the query parameters ` from=x-y-z ` and ` to=d-e-f ` .
34163417
34173418{{% boxes/warning %}}
0 commit comments