Images

Generation is JSON; edits and variations are multipart. All three use the application URL and key.

from openai import OpenAI

client = OpenAI(base_url="https://<llm-host>/<application-slug>/v1", api_key="<application key>")

client.images.generate(model="dall-e-3", prompt="A minimal TrustGate logo", size="1024x1024")

import OpenAI from "openai"

const client = new OpenAI({ baseURL: "https://<llm-host>/<application-slug>/v1", apiKey: "<application key>" })

await client.images.generate({ model: "dall-e-3", prompt: "A minimal TrustGate logo", size: "1024x1024" })

curl -X POST "https://<llm-host>/<application-slug>/v1/images/generations" \
  -H "X-AG-API-Key: <application key>" \
  -H "Content-Type: application/json" \
  -d '{"model": "dall-e-3", "prompt": "A minimal TrustGate logo", "size": "1024x1024"}'

/v1/images/edits and /v1/images/variations take model, image and, for edits, prompt as form fields. OpenAI SDKs work against the application base URL unchanged.

Which registries can serve it

OpenAI, Azure OpenAI, OpenRouter and OpenAI-compatible endpoints expose an images API. Anthropic, Gemini and Vertex, Bedrock, Mistral, Groq, xAI and Cohere do not, and are left out of the pool. Gemini’s native Imagen API is a different surface and not covered; so are images inside chat messages.

How it routes

Same as every capability: narrow to images-capable registries, then routing runs on that pool. Pinning a registry that cannot generate images is a 400; an empty pool is a 503. For multipart requests the gateway reads the form model field to apply the application’s model restrictions and to resolve Azure deployment names — and forwards the body as-is. It never rewrites multipart.

Start here

Concepts

LLM Gateway

MCP Gateway

Policies

Operate

Which registries can serve it

How it routes

​Which registries can serve it

​How it routes

Which registries can serve it

How it routes