Conversation resource returns 404 after exactly 60 days

Question

Hello all,

we are using the Microsoft Foundry Conversations API through the following endpoint:
GET /api/projects/{project}/openai/v1/conversations/{conversationId}

The conversation is created successfully and can be retrieved normally. However, after exactly 60 days, the same conversation_id consistently starts returning:
HTTP 404 Not Found

This happens across our conversations.

According to the Microsoft Foundry documentation, Conversations are described as durable/persistent conversation history. However, we have not found any documentation stating that Conversation resources have a 60-day retention or expiration period.

We are aware that other Foundry resources have different retention periods, including A2A tasks/contexts, but we are specifically using the Conversations API:

We would like to clarify:

• Does Microsoft Foundry currently apply a 60-day retention or expiration policy to Conversation resources?
• If not, what could cause a Conversation to return HTTP 404 after exactly 60 days?
• Is there any retention, cleanup, lifecycle, or inactivity policy affecting Conversations that is not currently documented?
• What is the recommended approach if Conversations need to remain accessible for longer than 60 days?

Any clarification or guidance from the Microsoft Foundry team would be greatly appreciated. Thank you in advance for your help.

Answer 1

Hi PG Development,

There is currently no documented 60-day retention limit for Microsoft Foundry Conversations. Microsoft’s current documentation states that conversation data persists unless you explicitly delete it. The 60-day retention documented for A2A tasks and contexts is a separate mechanism.

One thing to verify is whether the same project and x-ms-user-isolation-key are being used when retrieving the conversation, because that key can scope conversations to an end user.

If the conversation still returns 404 at exactly 60 days with the same project and isolation context, that does not match the documented behavior. I would raise this with Microsoft Foundry Support and provide a few affected conversation IDs, their creation timestamps, and the exact 404 responses so the service team can check the backend retention/lifecycle logs.