Export API - retrieving chats initiated by external users

Question

Export API - retrieving chats initiated by external users

Eran Otmi 60

Hi!

I have the following scenario:

a Teams chat was initiated by an external user (company B)
with a user from my organization (company A)

When calling the /getAllMessages endpoint for the user from my org (company A),
I can't find the chats that were initiated by the external user (company B).

Is that by-design?
Do I need to follow a different process to retrieve those chats?

Thanks

0 comments

1 answer

Your answer

Answer 1

Ana Le 1,895 Independent Advisor

Hi,

Based on your description, this behavior can be expected depending on the type of external chat.

The /users/{id}/chats/getAllMessages Teams Export API is intended to export messages that are available to your tenant. For federated (External Access) chats that were initiated from another tenant, those conversations may not be returned by the Export API from your tenant, even if one of your users participated in the chat.

Could you please confirm whether the external user is:

Using External access (federation), or
Added as a B2B guest in your tenant?

If this is an External access (federation) scenario, there isn’t a different Export API endpoint to retrieve those conversations if they are not returned by getAllMessages.

If you can share:

whether this is a 1:1 or group chat,
whether the external user is a federated user or a guest,
and whether you’re using the Microsoft Teams Export API (/users/{id}/chats/getAllMessages),

I will take a closer look and see if there are any additional considerations specific to your scenario.

Eran Otmi 60 Reputation points

2026-08-05T10:27:34.38+00:00
Hey!
Thanks for the answer.

both 1:1 and group chats

external user is a guest

I am calling both /getAllMessages, and /users/{id}/chats -> and can't find the chat_id in that endpoint

I am able to retrieve some of the conversations but it's not consistent,
and I am trying to understand under which circumstances I am able and unable to retrieve those chats.
Ana Le 1,895 Reputation points Independent Advisor

2026-08-05T11:33:40.49+00:00
Hi,

Thank you for the additional details. That helps clarify the scenario.

Since you're able to retrieve some guest conversations, but not others, it sounds like there may be specific conditions affecting which chats are returned.

Could you help clarify a few points?

Were the missing chats created before the user became a guest in your tenant, or after?

Can the user still see those chats in the Teams client?

Are the missing chats completely absent from /users/{id}/chats, or do they appear there but not in /getAllMessages?

If possible, it would also be helpful if you could share:

A sample chat ID from one conversation that is returned.

The approximate creation date of a similar conversation that is not returned.

That comparison may help determine whether the behavior is related to how the chat was created or whether it could be an issue with the API itself.
Eran Otmi 60 Reputation points

2026-08-05T11:53:19.54+00:00
Hey,
I am sharing the original test we made and the clarifications I would be happy to recieve:
Methodology

The replication was performed in two steps, mirroring the pipeline:

Step 1 — Fetch chats GET /users/{user}/chats with $expand=members,lastMessagePreview and a date filter on lastMessagePreview/createdDateTime. Results were paginated via @odata.nextLink and saved across 3 pages (call1.json → call3.json).

Step 2 — Fetch messages GET /users/{user}/chats/getAllMessages filtered on lastModifiedDateTime for 2026-07-23. Results were paginated and saved, then filtered down to the 5 known test case chat IDs.

The Graph calls were chosen to mimic the connector as closely as possible: same endpoints, expand/filter parameters, day window (UTC), and full @odata.nextLink pagination as in teams-e5-importer. No chat-scoped message APIs were used; message export followed the same getAllMessages path as production ingestion.

Results

Chats fetched (Step 1)

We expected 6 chats in which Pedro is present (ground-truth test cases for this user/date). Across the 3 pages of chat results, only 5 chat IDs were returned — one expected chat was missing from the list chats response entirely.

Messages fetched (Step 2)

5 out of 6 chats founds, 1 was not found:

chat id / type / messages found:

19:e207ad2cb2be44918a71160cb052a16c@thread.v2
Group chat

0 messages found

Key Finding

Missing chat from list chats: relative to the expected set of 6 chats with Pedro present, one chat never appeared in the /chats response for 2026-07-23, so it could not be ingested via the list-driven path at all.

Chat listed but no messages: the chat 19:e207ad2cb2be44918a71160cb052a16c@thread.v2 was returned by the chats API (Step 1) but produced zero messages in the getAllMessages call (Step 2).

This is significant for two reasons:

The chat exists and was active on 2026-07-28 — it appeared in the chat list filtered by lastMessagePreview/createdDateTime, confirming activity on that date.

The test case corresponding to this chat we expect to be missing from one of the environments, making this the most likely source of the observed discrepancy.

This points to a gap between what the two API calls surface: the chat-level API (/chats) reflects the chat as active, while getAllMessages does not return its messages for the same time window. This is a known behavioral inconsistency in Microsoft Graph — the two endpoints do not share the same underlying index, and replication lag or eventual consistency between them can cause a chat to appear in one response but not the other.

Hypothesis

Primary cause — Microsoft Graph eventual consistency. The discrepancy between the two environments is likely driven by API-level behavior, not a defect in how the connector maps a successful Graph payload. getAllMessages indexes messages differently from the chat-level /chats endpoint; depending on when each environment calls Graph during its daily ingestion window, one may observe a chat or message that the other misses (indexing lag, filter-window boundaries). That fits random rather than systematic gaps across runs.

This was confirmed by the data observed we fetched from Graph API.

Secondary cause (lower probability) — long processing window and Redis caching. With a large monitored-user set, previous-day ingestion can run for many hours (~19–21h). The importer marks each chatId:importDate in Redis after the first successful publish (TTL ~12h), so later users skip that chat. If the first publisher saw a thin or empty Graph result, or if environments differ in queue order / Redis state, internal dedup could contribute to missing chats or messages — but for this manual single-user replication the Graph gaps above remain the stronger explanation.

Questions to clarify with Microsoft

1. Inconsistency between /chats and getAllMessages

Why can a chat appear in GET /users/{id}/chats with lastMessagePreview/createdDateTime on day X, while getAllMessages filtered on lastModifiedDateTime for the same day returns zero messages for that chatId?

Is eventual consistency between these endpoints expected? If so, what is the typical indexing lag / any published SLA guidance?

2. Completeness of list chats

Why would only 5 of 6 expected chats (e.g. chats where a given participant such as Pedro is present) appear in list chats with the day filter, for the same user and date?

Does list chats with lastMessagePreview/createdDateTime gt {day}T00:00:00.000Z guarantee every chat with Teams UI activity on that calendar day, or only a subset of the indexed preview data?

3. Filter semantics

lastMessagePreview/createdDateTime (list chats) vs lastModifiedDateTime (getAllMessages) — these appear to use different indexes. What is Microsoft’s recommended pattern to capture “everything visible in Teams for calendar day X”?

For messages created on one day and modified on another, which filter should compliance export use so items are neither missed nor double-counted incorrectly?

4. Export vs Teams UI (federated / meeting / group)

getAllMessages is a mailbox / Teams export API. Does it guarantee the same message set as the Teams UI for group chats, federated 1:1, and meeting chats?

What conditions (licenses, XTAP, retention, guest vs home-tenant identity) can make the export thinner than the UI?

5. Pagination

With $top and full @odata.nextLink pagination until exhaustion, can chats or messages still be omitted due to cursor / consistency behavior even when nextLink is followed to the end?

6. Same chat, different members — identical message export?

For a given chat X and the same day / lastModifiedDateTime filter, can Microsoft confirm that getAllMessages for user A returns the same set of messages (same message IDs / content) as for user B, when both A and B are members of that chat?

If not guaranteed, what can cause per-member differences (mailbox indexing, licenses, guest vs home-tenant identity, retention, timing / eventual consistency)?
Ana Le 1,895 Reputation points Independent Advisor

2026-08-06T04:21:35.1266667+00:00

Hi,

Thank you for taking the time to document your testing in such detail. The methodology and observations are very clear, and it's helpful that you reproduced the behavior using the same Graph calls, filters, and pagination as your production pipeline.

Based on what you've shared, I don't see anything that suggests an issue with how you're handling pagination or using the Graph APIs.

The questions you've raised are primarily about the internal behavior of the Microsoft Graph service. For example, the relationship between the /users/{id}/chats and /users/{id}/chats/getAllMessages endpoints, indexing behavior, consistency between those endpoints, and whether differences between the Teams UI and the Export API are expected under specific scenarios.

As a fellow Microsoft Community user, I don't have visibility into the Graph service internals, so I wouldn't want to speculate or confirm whether the behavior you've observed is expected, a known service limitation, or an unexpected service issue without official confirmation.

Given the quality of the investigation you've already completed, I think the next step would be to open a Microsoft Support ticket. Your findings, including the Graph requests, timestamps, chat IDs, and the side-by-side comparison, should provide the engineering team with enough information to review backend logs and determine whether this is expected behavior or a service issue.

Please feel free to share the outcome if you receive an update from Microsoft. I'd be interested to know what they confirm regarding these scenarios.

Export API - retrieving chats initiated by external users

1 answer

Results

Chats fetched (Step 1)

Messages fetched (Step 2)

Hypothesis

Questions to clarify with Microsoft

1. Inconsistency between /chats and getAllMessages

2. Completeness of list chats

3. Filter semantics

4. Export vs Teams UI (federated / meeting / group)

5. Pagination

6. Same chat, different members — identical message export?

Your answer

1. Inconsistency between `/chats` and `getAllMessages`