Microsoft-graph-docs: Get all messages channel with their replies

[jerem99]

Is there a way to retrieve all messages with their replies in one request?
It does not seem efficient to read through every message and check if it has replies.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 701a6812-452b-7724-dc1b-635fc90736c9
• Version Independent ID: c956e3e9-d914-346a-799d-f00707fd786a
• Content: List channel messages - Microsoft Graph beta
• Content Source: api-reference/beta/api/channel-list-messages.md
• Product: microsoft-teams
• GitHub Login: @nkramer
• Microsoft Alias: MSGraphDocsVteam

[allaboglaeva]

I was able to add odata to the end ?$top=100 to increase the count. I got 50 back. Not sure if this helps you. Even though it's not supported it still works . https://docs.microsoft.com/en-us/graph/query-parameters , I was also able to use Skip. so maybe you can page

[akudhingra]

I was able to add odata to the end ?$top=100 to increase the count. I got 50 back. Not sure if this helps you. Even though it's not supported it still works . https://docs.microsoft.com/en-us/graph/query-parameters , I was also able to use Skip. so maybe you can page

I don't think @jerem99 wants to get all results on one page.

The issue is that the /channels/id/messages endpoint only returns a list of root messages without any replies. To get the replies for a message, you need to query a different endpoint (/channels/id/messages/id/replies) for each root message, which is pretty inefficient.

[andysturrock]

+1 for this. There isn't even (as far as I can see) anything on the parent message itself to indicate that it has a reply. So you have to call GET /teams/{id}/channels/{id}/messages/{id}/replies on every single message in the channel to check whether it's got a reply. At least if there was something on the parent you could only call the reply API for the messages that have replies.

[wazawski]

Seems like a heavy request though to get all messages and their replies.
I think getting the total number of replies when getting the parent message could be a good starting point to deal with the issue IMHO.

[oitptobbe]

When you request the messages you will get a @odata.nextLink property in the json. Call this url to get the next set of messages, if there is no such property then the channel doesn't seem to contain any more messages.

[dgancho]

@wazawski I am with you. A prop such as "(int)repliesCount" or even "(bool)hasReplies" would allow deciding whether to skip this root message or query it for replies.
@oitptobbe You seem not understanding the issue - it's not about getting all root messages in pages, it's about getting all root messages + all replies without looping thru each root message.

[andysturrock]

Yes I agree with @dgancho. Having to query each message in turn just to see if it has a reply is beyond stupid as an API design. Frankly Slack does this a million times better with both their RESTful style APIs and their RealTime Messaging APIs. The SDKs are miles better than the Teams ones too.

[TIvanyo]

I'd love to have a property that lets me know if a message has replies or not just like @dgancho suggested. Slack has it for their new API and it saves a lot of time and needless calls from being made.

[hafarey]

At least it looks to me like the returned list of root messages is sorted by the created dates of both root messages and reply messages. Any root messages that are out of order therefore means that the root message has jumped ahead from its original position in the list, because it contains one or more new replies.

Based on that, I'm trying to see if it would be possible to avoid a full-list scan. (...This feels like one of those algorithm problems they give you in dev interviews.)

[hafarey]

Disregard my previous comment. The following scenario already shows that my idea won't work in general:

Given root messages submitted in this order:

• Root1, Root2, Root3, Root4 (Root4 is most recent)

If one reply is submitted to each root in this order:

• Reply1, Reply2, Reply3, Reply4

Then the call's returned list will still return the same order of root messages:

• Root1, Root2, Root3, Root4

And consequently, the client will still have to request for the replies of each of the root messages.

[cgronseth]

This is ridiculous, a simple query of some teams 700+ messages is taking hours and thousands of requests because I have to query each message AND each reply. Why replies? Because I have to prepare the code in case multi-level replies are ever enabled!

Ok, it's a preview, I don't expect full OData-Expand right now but at least a member with "HasReplies" in the message data would save us a lot of flooding. Thanks.

[latonita]

we need this messages api to support $expand to be able to get replies.
and good to have support for $select to minimize data transfer if needed

so in the end i would love to get messages with replies as
.../messages?$expand=replies

and with support of $select as
.../messages?$select=(id,from,body)&$expand=replies($select=id,from,body)

right now, unfortunately, in case I use $expand i get error
The query specified in the URI is not valid. Query option 'Expand' is not allowed. To allow it, set the 'AllowedQueryOptions' property on EnableQueryAttribute or QueryValidationSettings.

[evandrogrm]

@latonita very good solution, same problem here. But unfortunately, only the $top param is allowed in this request.

[evandrogrm]

Also I questioned in StackOverflow and seems like a few wants the features and nobody cares =/

[gwalkey]

Break out the paging machine guys

[Vashishtha]

I think API to get reply should also come with delta link,
How many replies will be returned in one call is not specified, I think if replies are more delta link will be more efficient instead of going through whole list again.