Microsoft Foundry Agents Responses API suddenly rejects Base64 input_image data URIs

Question

Microsoft Foundry Agents Responses API suddenly rejects Base64 input_image data URIs

Armen Moloian 0

Two previously working Power Automate flows began failing on July 30, 2026 when calling a Microsoft Foundry agent through the Responses API.

Service: Microsoft Foundry

Region: East US 2

Agent: MLAIntakeReviewer, Version 28

Endpoint pattern:

https://[resource].services.ai.azure.com/api/projects/[project]/openai/v1/responses

Both flows submit an image using this documented Responses API structure:

{

"type": "input_image",

"image_url": "data:image/jpeg;base64,[image data]",

"detail": "high"

}

The endpoint now returns HTTP 400 with:

code: invalid_payload

message:

'data:image/jpeg;base64,...' is not a valid absolute URI.

parameter:

input[0].content[1].image_url

The same request structure worked previously. The failure was reproduced independently in both of these flows:

MLA AI Vision Test Bench
MLA AI Vision Power Automation

The Power Apps trigger and preceding Power Automate actions succeed. The first failed action in each flow is the HTTP request to the Foundry Responses API.

No application, prompt, agent-version, or image-encoding change preceded the failure.

Can Microsoft confirm whether Base64 data-URI support for input_image has regressed or whether the Foundry Agents endpoint introduced a schema change requiring an HTTPS URL?

If this is a service regression, please escalate it to the Microsoft Foundry engineering team.

Anshika Varshney 15,115 Reputation points Microsoft External Staff Moderator

2026-07-31T21:01:00.7933333+00:00

Hello @Armen Moloian

Did you get any chance to review the response.

Thankyou!
Anshika Varshney 15,115 Reputation points Microsoft External Staff Moderator

2026-08-03T05:23:52.6233333+00:00

Hi @Armen Moloian

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Thankyou!
Armen Moloian 0 Reputation points

2026-08-03T18:30:12.69+00:00
Thank you for the quick and detailed response. The Azure Blob Storage approach using a short-lived SAS URL appears to be a workable and supportable solution for our production flow.

Before we implement that architectural change, however, we would appreciate clarification on whether the rejection of Base64 image data is:

an intentional limitation of Foundry Agents using the Responses API,

a temporary service regression, or

an issue that has now been corrected.

We understand that a similar reported issue was subsequently corrected and that Base64 image input began working again. Since direct Base64 input would eliminate temporary storage, SAS-token generation, cleanup, and additional security handling, it would remain our preferred design if Microsoft considers it officially supported and stable.

Could you please confirm the currently supported behavior for our endpoint and whether you recommend Azure Blob Storage as a permanent production architecture or only as an interim workaround?

Thank you,

Armen
Anshika Varshney 15,115 Reputation points Microsoft External Staff Moderator

2026-08-05T03:48:59.1+00:00

Hello @Armen Moloian

Thank you for the follow-up question.

Based on the information currently available, we are unable to definitively confirm whether the recent behavior is due to a service regression, an intentional change, or a correction that has been fully rolled out. The behavior is still being reviewed by the engineering team.

From the documented guidance and previous investigations, the most consistently supported and recommended approach for image input with Foundry Agents is to provide the image through an HTTPS-accessible URL, such as an Azure Blob Storage SAS URL, rather than relying on inline Base64 data URIs. There have been reports where Base64 image inputs resulted in schema validation or URI validation errors when used with Foundry Agents through the Responses API.

While we understand the architectural advantages of direct Base64 input, we cannot currently provide an official guarantee that Base64 image data is a supported and stable production pattern for Foundry Agents using the Responses API. The HTTPS URL approach remains the supported production design that we recommend at this time.

We appreciate that this may introduce additional storage and lifecycle management considerations. If we receive any official confirmation from the product team regarding the long-term support status of Base64 image inputs, we will be happy to share that update.

If these steps resolve your issue, please mark this answer as Accepted so others can easily find the solution. If you still face problems, share additional details and we’ll assist further.

Thank you for your patience and understanding.

1 answer

Your answer

Anshika Varshney 15,115 Reputation points Microsoft External Staff Moderator

2026-07-31T21:01:00.7933333+00:00

Hello @Armen Moloian

Did you get any chance to review the response.

Thankyou!
Anshika Varshney 15,115 Reputation points Microsoft External Staff Moderator

2026-08-03T05:23:52.6233333+00:00

Hi @Armen Moloian

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Thankyou!
Armen Moloian 0 Reputation points

2026-08-03T18:30:12.69+00:00

Thank you for the quick and detailed response. The Azure Blob Storage approach using a short-lived SAS URL appears to be a workable and supportable solution for our production flow.

Before we implement that architectural change, however, we would appreciate clarification on whether the rejection of Base64 image data is:

an intentional limitation of Foundry Agents using the Responses API,

a temporary service regression, or

an issue that has now been corrected.

We understand that a similar reported issue was subsequently corrected and that Base64 image input began working again. Since direct Base64 input would eliminate temporary storage, SAS-token generation, cleanup, and additional security handling, it would remain our preferred design if Microsoft considers it officially supported and stable.

Could you please confirm the currently supported behavior for our endpoint and whether you recommend Azure Blob Storage as a permanent production architecture or only as an interim workaround?

Thank you,

Armen
Anshika Varshney 15,115 Reputation points Microsoft External Staff Moderator

2026-08-05T03:48:59.1+00:00

Hello @Armen Moloian

Thank you for the follow-up question.

Based on the information currently available, we are unable to definitively confirm whether the recent behavior is due to a service regression, an intentional change, or a correction that has been fully rolled out. The behavior is still being reviewed by the engineering team.

From the documented guidance and previous investigations, the most consistently supported and recommended approach for image input with Foundry Agents is to provide the image through an HTTPS-accessible URL, such as an Azure Blob Storage SAS URL, rather than relying on inline Base64 data URIs. There have been reports where Base64 image inputs resulted in schema validation or URI validation errors when used with Foundry Agents through the Responses API.

While we understand the architectural advantages of direct Base64 input, we cannot currently provide an official guarantee that Base64 image data is a supported and stable production pattern for Foundry Agents using the Responses API. The HTTPS URL approach remains the supported production design that we recommend at this time.

We appreciate that this may introduce additional storage and lifecycle management considerations. If we receive any official confirmation from the product team regarding the long-term support status of Base64 image inputs, we will be happy to share that update.

If these steps resolve your issue, please mark this answer as Accepted so others can easily find the solution. If you still face problems, share additional details and we’ll assist further.

Thank you for your patience and understanding.

Answer 1

Hello Armen Moloian,

Thank you for reporting this issue and for providing detailed reproduction information.

Based on your description, the payload format using:

{

"type": "input_image",

"image_url": "data:image/jpeg;base64,<image-data>",

"detail": "high"

}

was previously functioning and is now returning:

HTTP 400 - invalid_payload

'data:image/jpeg;base64,...' is not a valid absolute URI

This behavior suggests that the service may now be performing stricter validation on the image_url field and interpreting it as a standard URI rather than accepting Data URI (data:) schemes. However, since no changes were made to your flows, agent version, or image encoding, and the issue started suddenly on July 30, 2026, it could indicate a recent service-side regression.

As an initial troubleshooting step, please verify whether the same payload reproduces the issue outside Power Automate, for example by calling the Responses API directly using Postman or a REST client. This helps determine whether the behavior is specific to the Power Platform connector path or affects the underlying Foundry Responses API itself.

If the issue persists across direct API calls, please let us know with below details in the private chat:

Foundry project endpoint
Region (East US 2)
Agent name and version
Timestamp of a failed request
Correlation/Request ID from the failed API call
Sample payload (with image data redacted)

In the meantime, as a potential workaround, you may test hosting the image in a secure storage location (for example, a SAS-protected Blob URL) and supplying an HTTPS URL instead of a Base64 Data URI to determine whether only Data URI handling is affected.

Please let us know whether you can reproduce the same error with a direct REST API call, as that information will help narrow down the root cause.

Thankyou!