OpenAI Image Variations API: what it does in 2026

What the Image Variations API does today

The Images reference documents POST /v1/images/variations as a way to create a variation of a supplied image. The endpoint supports dall-e-2 only. Its documented request examples include an image, output count (n), output size, response format, and an optional user identifier.

That matters because “variation” often describes a broader creative goal than the endpoint actually handles. It can be useful when the starting image itself should drive alternate outputs. It is not the current route for a detailed instruction such as “keep this package photo, remove the old return label, and add the new step number.”

For that kind of direction, OpenAI's image guide describes the image-edit endpoint and the Responses API image-generation tool. Image edits can use one or more source images and a prompt. A mask can identify the part to replace. GPT Image models support those current editing workflows.

Use a variation only for the job it can do

The variations endpoint has no documented prompt field. Do not write a prompt and assume it will steer the result. If words need to control the edit, use an endpoint that accepts a prompt instead.

The current Images API reference shows a simple variations request shape:

curl https://api.openai.com/v1/images/variations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -F image="@approved-product-photo.png" \
  -F n=2 \
  -F size="1024x1024"

Use a non-production image while you prove the workflow. Store and review the returned asset before publishing it anywhere. A successful HTTP response proves only that the request returned an image. It does not prove that the variation preserves product details, uses the current policy, is accessible, or is suitable for customer support.

When a prompt-controlled edit is the better fit

The current image-edit guide is the right starting point when a creative brief has an explicit instruction. It supports existing images as references, and image edits can use a mask for a partial change. GPT Image output also has limits: OpenAI notes that precise text placement, visual consistency, and structured composition can still be difficult.

For a support-content team, that means a generated “how to photograph damage” example should not become a policy source. Keep the policy text in the help article. Treat the picture as an aid, test whether it shows the real item and the required evidence, and have the policy owner approve both before publication.

Test visual support content as part of the workflow

An image can make a return or installation step easier to understand, but it can also hide an error. Test the visual and its support workflow together:

• Use a representative set of products, damage cases, languages, and screen sizes.
• Check that the final image does not show a retired label, obsolete product, invented feature, or unreadable text.
• Compare the image, alt text, help article, and teammate instruction against the approved policy.
• Give testers questions where an image is insufficient and a person must make the decision.
• Keep the published visual separate from drafts and record who approved the version.

GPT Image models apply content filtering to prompts and generated images. That filter is not a substitute for your own product, policy, accessibility, or rights review. Handle blocked requests as part of the user experience rather than silently retrying the same invalid request.

Cost and operational checks

Do not use an old dall-e-2 price table as a forecast. Check OpenAI's current image pricing for the endpoint and model you will deploy. For GPT Image edits, OpenAI describes total cost as text input tokens, image input tokens, and output image tokens. Quality, size, output count, and reference-image use all affect the bill.

Measure a representative production-shaped run before you set a budget. Include the images rejected in review, retries caused by a changed brief, storage or delivery costs outside OpenAI, moderation handling, and human time to approve the final asset. A cheaper image is not a useful outcome if it sends a customer to the wrong step.

Use eesel CLI to keep the support explanation in sync

OpenAI's image endpoints are building blocks for visual generation and editing. eesel is a ready-to-work helpdesk teammate. The eesel CLI operates the same teammate and workspace as the dashboard. It does not call /images/variations, create visual assets, or choose an image model.

Here is a concrete use after a content team approves a new product-damage illustration and the help article that explains it. A support lead wants to know whether the helpdesk teammate has the approved article and the instruction to request a real customer photo when the illustration is not enough. The lead can use the dashboard, while a script or Claude Code, Codex, or Cursor reads the CLI's JSON output and creates a read-only report.

Start with Node.js 18.17 or newer. Authenticate and explicitly select the teammate to inspect:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents

TARGET_EESEL_AGENT="paste-agent-id-or-name-here"
npx @eesel/cli status --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli integrations --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli files ls --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli instructions --agent "$TARGET_EESEL_AGENT"

Ask the coding agent to report which sources are connected, whether content has downloaded, which standing instructions cover damaged goods, and whether the approved article or file appears where expected. It must not connect an account, change permissions, upload a file, or enable automation as part of that review.

If the policy owner approves adding an updated PDF or article export, preview the write before it runs:

npx @eesel/cli files upload ./approved-damage-photo-guide.pdf --agent "$TARGET_EESEL_AGENT" --dry-run

After the owner confirms the preview, run the approved upload and then create a fresh test conversation. Before testing, contain or disable actions outside the test scope. A held-action queue does not control an action that can run without a hold.

npx @eesel/cli files upload ./approved-damage-photo-guide.pdf --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli new --name "damage-photo-guidance-check" --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli chat "A customer says their parcel arrived damaged. Explain what photo evidence to send, using the approved guide. Do not promise a refund or replacement; state when a human must decide." --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli approvals --agent "$TARGET_EESEL_AGENT"
npx @eesel/cli activity --agent "$TARGET_EESEL_AGENT"

Review the answer for the correct evidence request, policy boundary, and handoff. The CLI chat is a test of the support teammate, not an image-variation call and not proof that an external order action succeeded. Confirm the actual helpdesk or order-system result before telling a customer that a refund, replacement, or follow-up occurred. Setup and observation commands are free; CLI chat is billed work, so scope the test deliberately.

The Integrations page lists connected platforms, sources, and items added to the teammate.

Choose the layer that owns the job

Use the Image Variations API when a dall-e-2 variation of one source image is the narrow job you need. Use current image edits or the Responses API when a prompt-controlled change or multi-turn visual workflow is the better fit. In every case, own the asset review and the content claims the image can influence.

Use eesel when the immediate job is operating a helpdesk teammate that explains approved support content. The CLI gives people, scripts, and coding agents a terminal route into that same teammate, while support owners keep approvals, tests, and outcome verification in the loop.

If you want to test the support guidance around a new visual before customers rely on it, try eesel and read the CLI guide.