I cannot perform image generation with model gpt-image-1.5 with github.com/openai/openai-go/v3 latest version

Hello Karnam,

Thanks — this explanation matches part of what we saw (Azure expects deployment-scoped routing for image generation), but one important detail is missing, and following the “use deployment name as the model” advice led us to a different failure.

What we tried after this

We initialized the Go client with openai.NewClient(azure.WithEndpoint(...), azure.WithAPIKey(...)) as recommended, then set ImageGenerateParams.Model to our actual Azure deployment name (the same string that appears in the working REST URL under /deployments/<name>/), to align with the suggestion to reference the deployment rather than a public model id.

What error we got

The service returned HTTP 400 with a message like:

Model not supported with Responses API. Supported models are: ['gpt-image-1', 'gpt-image-1-mini', 'gpt-image-1.5']

So the request was being validated as if model had to be one of those canonical names, not our long deployment id.

Why the Go SDK is involved

1. Images.Generate always posts to a relative path, not a deployment URL. (http://pkg.go.dev/github.com/openai/openai-go/v3@v3.30.0#ImageService.Generate) In openai-go, image generation uses path images/generations and delegates to the shared request stack:

   
      func (r *ImageService) Generate(...) {
   
      	path := "images/generations"
   
      	err = requestconfig.ExecuteNewRequest(ctx, http.MethodPost, path, body, &res, opts...)
   
   

2. The JSON body includes a top-level "model" field when you set Model. (https://github.com/openai/openai-go/blob/da6db3bace003b42c2465545f47401c1fb40c646/image.go#L1156) The struct documents model as DALL·E / GPT image product names (gpt-image-1.5, etc.), not Azure deployment names:

   
      // The model to use for image generation. One of `dall-e-2`, `dall-e-3`, or a GPT
   
      // image model (`gpt-image-1`, `gpt-image-1-mini`, `gpt-image-1.5`). ...
   
      Model ImageModel `json:"model,omitzero"`
   
   

   So the SDK is designed around OpenAI-style model values in the body, while Azure’s working REST call for us only put the deployment in the path and used a minimal body (prompt, size, n) without model.
3. Azure support in this SDK rewrites the path by reading that same model field from the body (getJSONRoute → /openai/deployments/<model>/...), but it does not remove model from the payload. So if you set Model to the deployment name to fix routing, Azure may still receive "model": "<deployment-name>" and reject it with the 400 above. If the path rewrite does not run or does not match (e.g. path not exactly /images/generations when middleware runs), we also observed requests hitting .../images/generations without /openai/deployments/..., which matches the earlier DeploymentNotFound story.
4. Request construction order: requestconfig.Execute resolves the base URL before wrapping http.Client.Do with middleware, so correct behavior depends on the middleware seeing the expected path and a readable body; that’s all inside the SDK, not something the caller can fix with endpoint configuration alone:

   
      cfg.Request.URL, err = cfg.BaseURL.Parse(strings.TrimLeft(cfg.Request.URL.String(), "/"))
   
      // ...
   
      for i := len(cfg.Middlewares) - 1; i >= 0; i-- {
   
      	handler = applyMiddleware(cfg.Middlewares[i], handler)
   
      }
   
   

So

The original answer is directionally right about deployment-based URLs, but “put the deployment name in the model field” is not reliably correct for Azure image generation with this SDK: the same field drives both path rewriting and the model JSON parameter, which triggered the 400 / model mismatch for us. A REST call that matches docs for our environment uses deployment in the path and no model in the body (or a canonical model name where the API requires it), which the high-level ImageGenerateParams flow does not mirror exactly.

So the problem is still not solved with your suggested approach :(

Hello Abhay Tiwari,

Glad to know that the earlier response was directionally helpful. Thank you for providing additional details.

To further resolve the error, please check if the following help:

• Calling the Azure image generation REST endpoint directly (deployment in path) as this bypasses the SDK ambiguity and matches the Azure routing contract.Please use the Azure REST shape as POST https://<resource-name>.openai.azure.com/openai/deployments/<deploymentname>/images/generations?api-version=<api_version> Body: start minimally with prompt, size, n, quality. If the service requires a model field for the chosen api-version, use the canonical model name (e.g., gpt-image-1 or gpt-image-1.5) — while keeping the deployment in the URL. How to Use Image Generation Models from OpenAI - Microsoft Foundry | Microsoft Learn Azure OpenAI - model parameter in request body causes failures when deployment name differs from model name · Issue #2892 · openai/openai-python
• Using the Azure “azopenai” Go package - There is an Azure SDK extension module for Go that is explicitly positioned to simplify Azure OpenAI usage with Go and includes Azure-specific examples (including image creation).

azopenai package - github.com/Azure/azure-sdk-for-go/sdk/ai/azopenai - Go Packages

In summary please , try the following

• Use deployment‑based routing for image generation requests. Ensure the request is sent to a deployment‑specific path in the format: /openai/deployments/<deployment-name>/images/generations Requests sent to a generic /images/generations path may fail with deployment resolution or validation errors.
• When using the Go SDK for image generation, avoid setting the deployment name in the model field if the SDK sends that value unchanged in the request body. Image generation endpoints validate the model field against supported canonical image models and may reject deployment identifiers.
• For scenarios where the Go SDK does not correctly handle deployment routing for images, use one of the following approaches:
• Call the Azure OpenAI Image Generation REST API directly, specifying the deployment name in the request path and keeping the request body minimal (prompt, size, count, quality).
• Use the Azure OpenAI Go SDK extension (azopenai), which is designed to align more closely with Azure deployment‑based routing patterns.
• If a model field is required in the request body by the selected API version, use a supported canonical image model name (such as gpt-image-1, gpt-image-1-mini, or gpt-image-1.5) while keeping the deployment reference in the URL path.
• Confirm that the Azure OpenAI resource endpoint follows the exact format: https://<resource-name>.openai.azure.com Avoid adding extra path segments when configuring the base endpoint.
• Validate that the image generation deployment is fully provisioned and available in the selected region before retrying requests.
• If errors persist, compare a known‑working REST request against the SDK‑generated request to confirm: deployment name appears only in the URL path and request body does not contain an unsupported deployment identifier in the model field

Thank you

Thank you for this quick response — this lines up with what we’re seeing, and the distinction between deployment in the path vs model in the body is exactly where things break with the high-level Go client.

REST / curl works for us

We already verified the Azure contract with a direct call (no Go SDK). For reference, our working request looks like this:

• Method / URL POST https://eastus2.api.cognitive.microsoft.com/openai/deployments/<OUR_DEPLOYMENT_NAME>/images/generations?api-version=2024-12-01-preview (We use the regional Cognitive Services host that matches our resource; the same shape applies with https://<resource-name>.openai.azure.com/... if that is what the resource exposes.)
• Headers Api-Key: <key> Content-Type: application/json
• Body (minimal, like you suggested) {"prompt": "a cat", "size": "1024x1024", "n": 1} No model field — deployment is only in the URL path. This succeeds.

So the “try REST with deployment in path” suggestion is not hypothetical for us; curl/REST is our known-good baseline.

What we tried in Go (and why it still fails)

We followed the earlier guidance to use openai.NewClient with azure.WithEndpoint, API version, and azure.WithAPIKey / token auth. We then:

• Set Model to the Azure deployment name so the Azure middleware could rewrite to /openai/deployments/<name>/images/generations — we then got 400 with a message that the model value is not supported (service treating body model like the Responses / canonical model list, e.g. gpt-image-1.5, not our deployment id).
• Set Model to a canonical name (gpt-image-1.5) while keeping deployment alignment — we hit DeploymentNotFound or requests that still appeared to hit a generic /images/generations path in error logs, depending on version and path handling.
• Compared SDK-logged URLs to the working curl: when the effective URL lacks /openai/deployments/<deployment>/..., Azure’s behavior matches DeploymentNotFound / wrong validation surface.

So we are stuck in a SDK-shaped problem: ImageGenerateParams always participates in building a body that may include model, while Azure image generation for us is correct only when routing is entirely in the path like our curl — and the community note about not putting the deployment id in model matches that.

On azopenai vs openai-go/v3

We did not ignore the Azure Go module. Per Microsoft’s own release notes, azopenai has been updated to work as a companion to the official OpenAI Go client and is tied to openai-go/v3 (see CHANGELOG — 0.9.0 / 0.8.0). So the same openai-go + azure middleware and request pipeline we are debugging is exactly the stack the migration path points to; “use azopenai” does not automatically sidestep the model vs deployment-in-path tension for image generation unless the examples/API surface there omits or overrides model the way REST does.
-> for more reference we are already following your image generation go code example script (https://dori-uw-1.kuma-moon.com/en-us/azure/foundry/openai/how-to/dall-e?tabs=command-line%2Ckeyless%2Ctypescript-keyless&pivots=programming-language-go)

Ask

If there is an official, supported pattern for GPT image deployments where:

1. the URL is always /openai/deployments/<deployment>/images/generations, and
2. the JSON body does not send a deployment string as model (or sends only a canonical name when required),

please point to a concrete Go example (azopenai or openai-go) that matches that REST shape.

Thanks again — the checklist you posted is known and followed already; our only gap is SDK-generated requests that still diverge from that known-good REST shape.

any update here ?

Hello Abhay Tiwari,

Thank you for your patience and the detailed breakdown for validating the behavior against a direct REST call.

For Azure OpenAI image generation, the officially supported guidance is that requests are routed entirely via the deployment name in the URL path, in the form of

/openai/deployments/<deployment-name>/images/generations

The documented guidance below for GPT‑Image‑1 and GPT‑Image‑1.5 explicitly documents this deployment‑scoped REST pattern, and all working examples construct requests where the deployment appears in the URL while the request body contains only image parameters such as prompt, size, n, and `quality.

With reference to the same guidance below , at the REST level, Azure OpenAI does not require the deployment identifier to be repeated as the model field in the JSON body for image generation, and sending no model field at all is a valid and supported request shape when the deployment is specified in the path. This matches the behavior observed with the known‑good curl request.

How to Use Image Generation Models from OpenAI - Microsoft Foundry | Microsoft Learn

With respect to Go SDKs, there is currently no official Microsoft‑published Go example that mirrors this exact REST shape using openai-go/v3 image helpers. The ImageService.Generate surface in openai-go is designed around OpenAI‑style semantics where:

• The request path is always images/generations
• The model field serves dual purposes for routing and validation.

So this is creating a mismatch for image generation, where

• The routing must be deployment‑based via the URL
• The model field is validated strictly against canonical image model names (gpt-image-1, gpt-image-1-mini, gpt-image-1.5) rather than deployment identifiers.

As a result, currently there is no supported configuration in openai-go/v3 that simultaneously forces deployment‑scoped routing for images and omits or neutralizes the model field in the request body to exactly match the Azure REST documented guidance.

The only fully supported and documented pattern available today for Azure GPT image deployments is

• using direct REST calls as documented
• using SDKs whose API surfaces expose deployment routing explicitly and independently of the request body

Please review them in the same documented reference below -

How to Use Image Generation Models from OpenAI - Microsoft Foundry | Microsoft Learn

The deployment itself is healthy and correctly configured.The divergence is at the SDK request‑shape level rather than a service or configuration issue.

Thank you