Azure API Management OpenAI Swagger Validation Error with Vision Requests

[josephk]

I’m encountering issues with Azure API Management while trying to validate vision requests for OpenAI. After importing the Azure OpenAI swagger specification into APIM, I set up JSON validation by using the validate-content policy.

<validate-content unspecified-content-type-action="ignore" max-size="4194394" size-exceeded-action="detect" errors-variable-name="validationErrors">
    <content type="application/json" validate-as="json" action="prevent" allow-additional-properties="true" />
</validate-content>

Everything works fine for normal text inputs, but the validation seems to fail when I send visual requests containing image information. Here’s an example of the payload I’m testing:

{
    "data": [
        {
            "role": "system",
            "content": ""
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "analyze this image"
                },
                {
                    "type": "image_url",
                    "image_url": {
                        "url": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgo"
                    }
                }
            ]
        }
    ],
    "stream": true
}

When I send this request, the error message I receive is:

{
    "statusCode": 400,
    "message": "Request body doesn't match schema for application/json content type. Path: data[1].role Error: Value 'user' not found in enum. Line: 12, Position: 25 SchemaId: #/components/schemas/functionMessageRequest/properties/role"
}

From what I see, it appears the validator is referencing the incorrect schema (functionMessageRequest instead of userMessageRequest). Has anyone else faced this problem with the Swagger validation in APIM when working with OpenAI vision APIs?

[CreativePainter33]

APIM’s throwing this error because it can’t handle the content field structure in vision requests. The Azure OpenAI swagger spec doesn’t play well with polymorphic content - where the same field takes both strings and complex object arrays. I got around this by creating a custom policy that skips validation for vision models. Just check if the content array has objects with type image_url, then bypass validation for those calls. You could also modify the imported swagger to drop the strict enum constraints on the role field in message schemas. That functionMessageRequest schema reference means APIM’s using the wrong discriminator mapping. Try adding request transformation before validation to normalize the payload, or just exclude vision endpoints from content validation entirely while keeping it on for regular chat completions.

[sophialee92]

Hit the same issue a few months ago with GPT-4V through APIM. Problem was the OpenAI swagger spec handling polymorphic message content - where content can be either a string or an array of objects for vision requests. Fixed it by updating the swagger definition to handle content union types properly. Azure’s default OpenAI swagger has messy schema references that trip up APIM’s validator with mixed content types. Check if your imported swagger defines discriminator properties correctly for different message types. You’ll probably need to manually fix the schema definitions or grab a newer OpenAI spec that handles vision requests better. Also try loosening the validation policy while you troubleshoot - the allow-additional-properties flag often doesn’t cut it with complex nested schemas.

[MiaDragon42]

yeah, that’s a known apim validation bug. the swagger parser can’t handle when the content property switches between string and array formats. quick fix: change your validate-content policy to use unspecified-content-type-action=“prevent” instead of ignore, or just turn off validation for vision endpoints. the schema mapping breaks because apim tries matching all possible message schemas at once.