Microsoft groups - graph API does not return all posts in a thread/conversation

Question

Microsoft groups - graph API does not return all posts in a thread/conversation

Boopathi Krishnan 20

Hi team,

I am experiencing the issue that graph API does not return all posts in a thread/conversation , but it does not appear to be related to older posts being moved or soft-deleted. The posts are still present, and I have verified this with the following steps:

I sent an email to a group mailbox. This created one conversation, one thread, and one post.

I then replied to the same post using the Reply All option. As expected, the conversation preview and thread were updated. However, only one post (the latest post) is returned in the API response, instead of both posts.

Interestingly, I am still able to retrieve the older post content using the post_id that I had stored earlier.

Note: No separate thread was created as part of this reply.

If a conversation contains multiple posts, I expect to retrieve the full list of posts. However, in this scenario, the API returns only the most recent post, which leads to incomplete data retrieval.

APIs Used

Get single post:
GET /groups/{group_id}/threads/{thread_id}/posts/{post_id}

List posts:
GET /groups/{group_id}/threads/{thread_id}/posts

Request

Could you please confirm if this is expected behavior?
If so, is there any recommended workaround to reliably retrieve all posts within a thread?

This is critical for our backup use case, where complete conversation history is required.

Thanks in advance for your help.

Best regards,
Boopathi K

0 comments

1 answer

Your answer

Answer 1

This is expected behavior for the Microsoft 365 group conversation APIs being used.

The GET /groups/{groupId}/threads/{threadId}/posts operation returns the posts that currently belong to that thread, but the underlying group mailbox can change how messages are grouped into conversations/threads as users reply (especially via Outlook using Reply/Reply All). As a result, some replies that appear visually as part of the same conversation in the mailbox UI may not be exposed as multiple posts in the same thread via the Graph list posts API, even though individual posts remain addressable by their post_id.

Key points from the APIs involved:

GET /groups/{groupId}/threads/{threadId}/posts lists posts for the specified thread and supports $select and $expand, but does not guarantee that every message a user sees in the mailbox UI as part of that conversation will be returned as a separate post in that thread.
GET /groups/{groupId}/threads/{threadId}/posts/{postId} can still retrieve a specific post by ID, which matches the observation that the older post is still accessible when the post_id is known.

For a backup scenario where complete history is required, the practical workarounds are:

Persist each post_id as posts are first discovered (for example, by periodically listing posts or threads) and later rehydrate missing items with GET /groups/{groupId}/threads/{threadId}/posts/{postId}.
When creating conversations or threads programmatically (using POST /groups/{id}/conversations or POST /groups/{id}/threads), keep track of the returned conversation and thread IDs and then use list posts immediately after creation to capture all posts at that point in time.
For subsequent replies added via Graph, use conversationThread: reply or post: reply so that all posts created by the backup process itself are reliably discoverable through the same APIs.

There is no documented server-side option in these APIs to force all mailbox messages that appear in the UI to be surfaced as distinct posts in list posts. Designing the backup flow around stored post_id values and Graph-created conversations/threads is the supported way to ensure complete retrieval.

References:

Share via

Microsoft groups - graph API does not return all posts in a thread/conversation

APIs Used

Request

1 answer

Your answer