A fully managed platform in Microsoft Foundry for hosting, scaling, and securing AI agents built with any supported framework or model
Hello @Vlad Tkachenko
Based on the behavior you've described, I agree that this looks more like a schema/validation mismatch on the Foundry project-scoped endpoint than an issue with the request payload itself.
The important part is that Microsoft Foundry's current REST reference defines input_image.detail as part of the image input schema. The project-scoped Responses endpoint is:
POST {endpoint}/openai/v1/responses
where {endpoint} is the Foundry project endpoint.
More importantly, Microsoft currently publishes Responses API examples that explicitly use:
{
"type": "input_image",
"image_url": "...",
"detail": "original"
}
so original is clearly being used by Microsoft's current API documentation/examples.
If the same payload and model deployment succeeds against the Azure OpenAI /openai/v1/responses endpoint but fails only when routed through the Foundry project endpoint, that is a strong isolation result.
I would test the project endpoint with the smallest possible request and capture the complete HTTP response:
curl -i "$PROJECT_ENDPOINT/openai/v1/responses" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $TOKEN" \
-d '{
"model": "<deployment-name>",
"input": [{
"role": "user",
"content": [{
"type": "input_image",
"image_url": "<image-url>",
"detail": "original"
}]
}]
}'
Then repeat it changing only:
"detail": "original"
to:
"detail": "high"
If high succeeds and original is rejected by the project endpoint, while original succeeds through the Azure OpenAI resource endpoint, that would provide a very clean reproduction of the gateway/schema discrepancy.
I wouldn't recommend permanently changing the application to high merely to hide the problem. Depending on the model/API behavior, original and high shouldn't automatically be treated as semantically interchangeable.
Microsoft Moderator Golla Venkata Pavani: Could you please help escalate this to the Microsoft Foundry/Responses API engineering team? The current project-scoped Responses endpoint appears to reject an input_image.detail value that Microsoft's current API surface/examples represent, while the equivalent Azure OpenAI resource endpoint accepts the request.
For engineering correlation, Vlad, I would provide:
Foundry project region:
Model/deployment:
Project endpoint:
Failing detail value: original
Working detail value(s):
HTTP status:
Complete validation error:
x-request-id / request ID:
Exact UTC timestamp:
Please redact the bearer token/API key and any sensitive image URL before posting diagnostics publicly.
References:
Microsoft Foundry REST API reference
Microsoft – Computer Use with the Responses API example
Given that the documented value works through one Azure OpenAI API path but is rejected specifically through the project-scoped path, I wouldn't classify this as an application-side validation problem without further evidence. The next useful step is having Microsoft confirm whether the Foundry project gateway's validator is running an older/different schema, or whether the original currently has an undocumented restriction on that endpoint.
Please "Accept the Answer" if this information helped you. This will help us and others in the community.