Malformed JSON response to Graph API /me/messages endpoint

Question

Malformed JSON response to Graph API /me/messages endpoint

Partners Zapier 15

We have recently started seeing responses from the Graph API endpoint that have malformed JSON in the response. It ends with "value":[ and then no content beyond that. The status code is 200.

This does not happen with all requests, only some of them.

We saw a small percentage of these responses starting on Dec 22, but it greatly increased on Dec 30 and has continued at that level until now.

The number of daily requests we make to this endpoint is in the millions.

Endpoint

/v1.0/me/messages

Example Response Content

{"@odata.context":"https://graph.microsoft.com/v1.0/$metadata#users('12345678-abcd-abcd-abcd-12345678abcd')/messages(id,createdDateTime,lastModifiedDateTime,changeKey,categories,receivedDateTime,sentDateTime,hasAttachments,internetMessageId,subject,bodyPreview,importance,parentFolderId,conversationId,conversationIndex,isDeliveryReceiptRequested,isReadReceiptRequested,isRead,isDraft,webLink,inferenceClassification,sender,from,toRecipients,ccRecipients,bccRecipients,replyTo,flag,attachments(id,name,size,lastModifiedDateTime,isInline,contentType))","value":[

Manuel Hesselbarth 0 Reputation points

2026-01-08T06:11:43.3933333+00:00

Since the new year, we seeing the exact same thing, definitely related to the $search parameter in our case. If we omit it, result is ok, as soon as it is present, result is incomplete and cannot be parsed by the PHP Graph SDK.

2 answers

Your answer

Manuel Hesselbarth 0 Reputation points

2026-01-08T06:11:43.3933333+00:00

Since the new year, we seeing the exact same thing, definitely related to the $search parameter in our case. If we omit it, result is ok, as soon as it is present, result is incomplete and cannot be parsed by the PHP Graph SDK.

Answer 1

Partners Zapier 15

Thank you for the suggestions — we’ve investigated these areas further and wanted to share additional observations that may help narrow this down.

Based on what we’re seeing, the issue does not appear to be driven by overall response size, page size, or pagination:

We see successful responses with $top=1000 when using $filter + $orderby (without $search).
We see failures with much smaller $top values when $search is included.

This suggests the behavior may be correlated with the presence of $search, rather than general payload size or pagination limits.

In the failing cases, requests return 200 OK with headers indicating a streamed response (transfer- encoding: chunked and odata.streaming=true), but the response body terminates early:

{
  "@odata.context": "...",
  "value": [

No message objects or error details follow. From the client’s perspective, the response appears successful at the HTTP level but incomplete at the payload level.

Additional context:

We use a defined $select and $expand=attachments as part of our integration’s expected response shape; removing these would be a breaking change for existing usage.
Client-side retries do not resolve the behavior for affected tenants.

Sourcewhale 0 Reputation points

2026-01-06T14:18:50.33+00:00
Hello,

I wanted to add some findings from our own testing, as they seem to strongly support this being a service-side issue rather than client misuse.

We also saw the same spike in the number of these errors around the 30th December.

Summary of our investigation so far:

The issue reproduces as HTTP 200 OK with a truncated JSON body, typically ending after:
{ "@odata.context": "...", "value": [
with no message objects following. Pagination / page size does not appear to be the root cause: Failures still occur with $top=1
Successful responses are observed with much larger `$top` values in other query shapes **Retries do not reliably resolve the issue**, even with backoff.

Reducing $select does reduce frequency, but does not eliminate the problem:

Certain fields (notably recipients when included in $select) appear to increase the failure rate

However, no single $select field is a consistent trigger — failures remain intermittent even with minimal selects
Austin-H 7,575 Reputation points Microsoft External Staff Moderator

2026-01-06T14:22:57.1533333+00:00

Hi Partners Zapier
Thank you for your time.
We will conduct research about this and let you know about our finding.
Konstantin Severi 0 Reputation points

2026-01-07T15:05:29.46+00:00

Just adding here that we're running into the same issue - other requests seem to be working fine, but there is always an issue with the search query. Our response also looks the exact same - lists the @odata.context parameters, then cuts off on the value the the GraphServiceClient throws an exception.
Robin Messenger 0 Reputation points

2026-01-07T19:40:43.3766667+00:00

We have been running into the same problem with a $top value of 15. We can't reduce this any further without degrading user experience.

Answer 2

Jack-Bu 5,825 Microsoft External Staff Moderator

Hello Partners Zapier

Thank you for reaching out to Microsoft Q&A regarding the intermittent malformed JSON responses from the Graph API /me/messages endpoint. I've reviewed the details you provided, similar problems have been reported, often tied to large result sets, specific $select parameters, pagination handling, or internal service limits. While I couldn't find evidence of a widespread outage matching your exact timeline, here are some steps to help mitigate the issue:

Adjust query parameters to reduce response size: If your query includes a comprehensive $select clause, which may contribute to larger responses and potential truncation. Try minimizing the selected fields (like start with $select=id,subject,receivedDateTime) and add them back gradually to identify any triggers. Additionally, enforce pagination with smaller page sizes like $top=5 or $top=10, and handle the @odata.nextLink for subsequent pages. Narrowing filters, such as by date range or folder, can also help reduce result sets and avoid thresholds.
Test client-side retries and validation: To handle these intermittent issues, add logic to detect malformed JSON (e.g., check for proper closing braces during parsing) and automatically retry the request 1-3 times with exponential backoff. If you're not already using it, consider the Microsoft Graph SDK for your platform, as it provides built-in support for retries, pagination, and error handling, which can make your implementation more robust.
Try out different ways to query: For efficient bulk or ongoing fetches, consider switching to delta queries (/me/mailFolders/inbox/messages/delta) to track changes without full list retrievals, which is ideal for high-volume scenarios like yours. If the issue seems tied to specific users or mailboxes, test across a sample to isolate patterns.

If these steps don't fully resolve the problem, please provide additional details such as sample query parameters, client stack, or headers from affected responses in the comment bellow, I'm here to assist.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Austin-H 7,575 Reputation points Microsoft External Staff Moderator

2026-01-05T04:06:56.58+00:00

Hello Partners Zapier
May I know if you have checked on Jack's answer?
We are looking forward to hearing updates from your end.
Robin Messenger 0 Reputation points

2026-01-07T19:44:05.1866667+00:00

@Jack-Bu — we have been experiencing the same problem as Partners Zapier. Are you able to give us a timeline for when this bug will be fixed?
Jack-Bu 5,825 Reputation points Microsoft External Staff Moderator

2026-01-08T10:01:02.7366667+00:00

Hello Partners Zapier and Robin Messenger

Thanks for the detailed update and for sharing your investigation findings, that's really helpful in narrowing this down. It's clear from what you've described (the correlation with $search, the chunked streaming terminations, and the persistence even with small $top or reduced $select) that this is likely a service-side issue tied to how full-text searches are handled in the backend. The spike around December 30, 2025, aligns with what others have reported. In the meantime, based on your tests showing success with $filter and $orderby without $search, here's my recommendation to mitigate the impact.

Pivot to $filter-based queries as your primary workaround, since $search appears to be the clear trigger for these truncations, likely due to its reliance on more complex indexing and processing that can interrupt the streaming response under certain conditions. For keyword-based searches, swap in equivalents like contains(subject, 'keyword') or contains(body/content, 'keyword') combined with $orderby for sorting. This has proven reliable in your own tests without $search and should preserve most of your integration's functionality (including your defined $select and $expand=attachments) while sidestepping the issue entirely for compatible queries. It's the best option right now because it directly addresses the root correlation you've identified, requires minimal changes to your setup, and avoids the intermittency of retries or field reductions, which you've already seen don't fully resolve things. If fuzzy matching is essential for some scenarios, treat $search as a last-resort fallback only after verifying $filter works for that tenant.

Hope this help.
Partners Zapier 15 Reputation points

2026-01-08T19:28:56.3033333+00:00
@Jack-Bu @Austin-H Thank you for the responses and suggestion.

Confirming that minimizing the selected fields (for example just$select=id,subject,receivedDateTime) does not resolve the issue - any use of $searchgives that incomplete JSON

Attempts to follow the recommendation and use $filter instead are not workable. $filter and $orderby cannot be combined with the /messages endpoint, even if reducing the $top.

Requests as limited as

GET https://graph.microsoft.com/v1.0/me/messages?$top=3 &$filter=from/emailAddress/address eq '******@zapier.com' &$orderby=receivedDateTime desc&$select=id,receivedDateTime

give the error message

“Unable to retrieve the list of emails: The restriction or sort order is too complex for this operation.”

Neither using contains nor eq resolves the error.

The only request that succeeds without error is using $filter without any $orderby, in which case it is then not possible to request the most recent records as they are not returned by recency from /messages. Even if using top=1000 and sorting the response by receivedDateTime on our end, this will not guarantee users with larger inboxes see their most recent messages in that request.

Is there any further information available about the use of $search being a service wide issue and plans to resolve that change in behaviour?

The documentation here: https://learn.microsoft.com/en-us/graph/search-query-parameter?tabs=http still notes this is a supported param.
Partners Zapier 15 Reputation points

2026-01-14T21:05:48.9366667+00:00

Hi team,

A quick update that we have seen a drop in malformed JSON in responses from the /v1.0/me/messages endpoint over the last 20+ hours. The most recent malformed JSON response we could find was at 2026-01-13T12:04:15 UTC for us. In that case, we sw immediate recovery, as the impacted user who hit the error has had over 300+ successful calls since then (no malformed JSON, valid results were returned in the value property).

As mentioned, we make millions of requests to /v1.0/me/messages daily. So it is difficult to confirm if the issue is fully resolved. But we have strong evidence that for now, the issue is mitigated for the vast majority of users who previously saw the issue.

Can you confirm if there was a change on Microsoft's end that was taken, that fixed this issue? We'll be sure to update if a spike in malformed JSON occurrence resurfaces.
Jack-Bu 5,825 Reputation points Microsoft External Staff Moderator

2026-01-15T14:28:36.2266667+00:00

Hi Partners Zapier

Apologies for delay in response, and thanks for the update, I glad to hear the issue has been mitigated, and things are stable for most users in your high-volume setup. Regarding your question about a change on Microsoft's end: After checking our resources, service status pages, and related forums, I can confirm there was no official incident reported or public acknowledgment of a specific fix for this truncation problem with the /me/messages endpoint. It might have been resolved through routine backend optimizations or regional rollouts that aren't always documented publicly, but nothing formal has been announced.

I would like to suggest you visiting other community like https://techcommunity.microsoft.com/ or https://github.com/orgs/community/discussions for more developer insights.

Share via

Malformed JSON response to Graph API /me/messages endpoint

Endpoint

Example Response Content

2 answers

Your answer