OpenAI 图片生成 API Endpoint：该用哪个接口？

如果你今天要接 OpenAI 图片生成，最稳的默认路线不是先上 Responses，而是先走直接 Images API。单次出图用 POST /v1/images/generations，已有素材要修改用 POST /v1/images/edits，只有当图片生成只是更大多模态或 agent 工作流中的一个工具时，才切到 Responses 的 image_generation tool。

这件事之所以值得单独写一篇，不是因为 endpoint 名字本身有多复杂，而是因为 OpenAI 现在把答案分散在了几类页面里。主 image generation guide 讲的是 Images API 和 Responses API 的分工；Images API reference 才给出原始路径；image_generation tool guide 解释的是 Responses 里的工具调用；而官方 Images and vision 页面截至 2026 年 3 月 23 日 还在写最新模型是 gpt-image-1，这又和当前模型目录形成了错位。

所以这个关键词真正要解决的问题并不是“给我一个 URL”。真正的问题是：我现在这个任务，到底该从哪个调用面开始？ 如果你的目标是先证明“我能稳定拿到一张图”，就先用直接 Images API。等你真的需要把图片生成放进更大的推理流程时，再切到 Responses。

当前 OpenAI 图片接口路线，一张表先看懂

理解 OpenAI 当前图片栈，最有效的方法就是把直接图片任务和工具式多模态编排拆开看。

这张表背后的逻辑，与 OpenAI 当前官方文档是一致的。主 image generation guide 明确说有两条主路线，而且单张图片优先走 Image API。Responses 的 tool guide 适合的是另一类问题：图片输出只是更大推理链条中的一个工具步骤。

所以真正实用的规则很简单：没有充分理由时，先用直接 Images API。 这样你的第一条请求更容易调试，更容易交给同事复现，也更容易把问题限定在模型、权限和请求结构这三件事里。

如果你当前连模型名都还没选定，先看同语言的 OpenAI 图片生成 API 模型怎么选。这篇文章故意更窄，只负责把“接口到底该从哪一层开始”讲清楚。

单次出图，先从 POST /v1/images/generations 开始

对大多数新接入来说，这一步是最好的第一验证。当前 Images API reference 把 POST /images/generations 列为原始生成接口，落到真实调用就是 https://api.openai.com/v1/images/generations。而最新模型默认值，最适合锚定 在 GPT Image 1.5 模型页，因为它把 GPT Image 1.5 明确标成当前图像生成主线。

第一条请求最好故意“无聊”。一段 prompt、一张方图、一个当前主线模型，足够告诉你 API key、组织上下文、模型访问和请求结构是不是都正常。与其一上来就想同时解决透明背景、多图编辑、Responses 工具流和输出格式，不如先把这条最短路径跑通。

最小可运行的 cURL 示例可以这样写：

bash
curl https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-1.5",
    "prompt": "Create a clean editorial illustration of a robot camera operator in a bright studio",
    "size": "1024x1024",
    "quality": "medium"
  }'

如果你更习惯 SDK，那么 JavaScript 对应关系也很直接：

js
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const result = await client.images.generate({
  model: "gpt-image-1.5",
  prompt: "Create a clean editorial illustration of a robot camera operator in a bright studio",
  size: "1024x1024",
  quality: "medium",
});

这里还有一个很多教程会跳过的点：按照 Images API reference 的当前说明，GPT Image 系列默认返回的是 b64_json，不是现成可访问的托管 URL。也就是说，第一条成功请求不应该只看“HTTP 200 是否返回”，而应该确认你已经能把 base64 解码、保存，或转发给前端。这也是为什么我更建议先从直接 endpoint 开始，因为它把整条最小链路压缩得最清楚。

如果你想看完整的 JavaScript、Python、cURL 多版本示例，可以继续读同语言的 OpenAI 图片生成 API 示例。但在这篇 endpoint 文章里，重点不是多语言示例本身，而是先把路走对。

已经有素材时，用 POST /v1/images/edits

很多人搜索“image generation endpoint”，真正要解决的却不是纯生成，而是“我已经有一张产品图或参考图，应该怎么改”。这种情况下，更合适的当前路线仍然是直接 Images API，只不过从生成分支换成编辑分支。

根据当前 Images API reference，直接编辑的原始接口是 POST /images/edits。而主 image generation guide 也已经把 GPT Image 1.5 的 edit 示例直接放在 Images API 路线上。这一点很关键，因为它说明了：做图片编辑，并不意味着你应该自动切到 Responses。

SDK 版本同样很直接：

js
import fs from "fs";
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const result = await client.images.edit({
  model: "gpt-image-1.5",
  image: [fs.createReadStream("product-shot.png")],
  prompt: "Keep the product shape, but place it on a clean studio shelf with warm lighting",
  input_fidelity: "high",
});

这里之所以值得在 endpoint 文章里专门点出 input_fidelity: "high"，不是为了把参数讲细，而是为了强调：直接 edit 路线不是“入门版接口”。它就是 OpenAI 当前正式的图像编辑主路径。你应该离开它，只有一种情况，就是你的工作流本身已经变成需要更大推理链条、多工具协同或会话状态管理，而不是因为图片任务稍微复杂一些。

很多弱教程的问题就在这里。它们把一切图片工作都往 Responses 示例里汇总，好像只要是“更高级一点”的图片任务，就一定该切到 tool 流。这会让学习成本明显变高。只要你的任务仍然是“基于输入图片做修改”，直接 Images API 往往还是更清晰的选择。

如果你真正关心的是 mask、保真、input_fidelity、多图 compositing 应该怎么选，那就去看更细的 OpenAI 图片编辑 API 指南。这篇文章只需要把一条更重要的结论钉住：编辑是 Images API 的第一公民场景，不是自动切换到 Responses 的理由。

只有在图片生成只是更大流程中的一步时，才切到 Responses

Responses 的价值，不在于“它更新”，而在于它适合更大工作流。如果你的产品需要一个主线推理模型先理解任务、可能调用别的工具、可能继续对话，然后某个节点才决定生成图片，那么 image_generation tool 的抽象就比直接 image endpoint 更合适。

这里最容易犯的实现错误，是把 gpt-image-1.5 直接塞进 Responses 顶层 model 字段。当前 image_generation tool guide 讲得很清楚：GPT Image 模型是在工具背后被调用的，但这些模型 ID 不是 Responses 顶层 model 的合法值。

一个更合理的调用形态会是这样：

js
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const response = await client.responses.create({
  model: "gpt-5",
  input: "Generate a transparent sticker-style icon of a paper airplane for a travel app",
  tools: [{ type: "image_generation", background: "transparent", quality: "high" }],
});

这条路线是对的，但它解决的是另一类问题。它更适合以下场景：

1. 同一条请求既可能输出文字，也可能输出图片
2. 图片生成只是多工具流程中的一个节点
3. 你希望模型自己决定什么时候调用图片工具，什么时候继续推理

如果你现在真正要做的，只是确认“OpenAI 当前图片接口哪条最短、最稳”，那么 Responses 反而会把问题层数抬高：你还要管主模型、工具调用、工具输出解析，以及更间接的调试链路。

所以这里的原则不是“Responses 更新，所以优先”。真正的原则是：只有当编排本身才是你的真实问题时，Responses 才是更好的路。 如果你现在的真实问题还不是编排，那就先别给自己增加抽象层。

如果你想在这篇文章之后继续看更完整的调用路线，而不只是 endpoint 选择，可以接着看同语言的 OpenAI Image API 教程。

文档错位和权限检查，最容易把“对的接口”误判成“错的接口”

这一节是当前 SERP 处理得最差的地方。很多开发者以为自己 endpoint 选错了，真实问题却是文档新旧错位或者账户访问没准备好。

先说文档错位。截至 2026 年 3 月 23 日，官方 模型目录 把 GPT Image 1.5 放在当前图像主线上，GPT Image 1.5 模型页 也明确把它作为当前旗舰图像路线。但官方 Images and vision 页面仍然写着最新图片生成模型是 gpt-image-1。更早的 cookbook 示例 也还在用 gpt-image-1。

这不是说官方文档不能看，而是说你要知道每种页面该拿来解决什么问题：

1. 原始 endpoint 看 API reference
2. 当前模型新旧判断 看 all-model catalog 和 GPT Image 1.5 model page
3. 该走 Images API 还是 Responses 看主 image generation guide
4. 只有真的在写 Responses tool 流时 再看 image_generation tool guide

再说权限。当前 GPT Image 1.5 模型页明确写了 Free not supported，公开限额从 Tier 1 的 100,000 TPM 和 5 IPM 开始。而 API model availability 页面又单独说明，gpt-image-1 和 gpt-image-1-mini 的访问与 tier 1 through 5 以及组织验证相关。也就是说，你完全可能 endpoint 选对了，但账户还没准备好。

搜索生态里还有一层 rollout 噪音。OpenAI 自己的 GPT Image 1.5 rollout 讨论串 里，就出现过模型暂时不可见或报 model-not-found 的情况。那些上线阶段的讨论，之后往往会被旧教程、缓存片段、论坛答案继续引用。

因此更稳的排错顺序应该是：

1. 先确认路线是不是对的：Images API 先，Responses 只在需要时再上
2. 再确认模型默认是不是新的：GPT Image 1.5 作为当前主线
3. 再检查 tier、组织验证和 active org
4. 最后才去大改 payload 或 SDK 代码

如果你的真实问题是访问权限而不是接口路径，那比起继续乱换 endpoint，更应该直接看同语言的 OpenAI 图片生成 API 验证与权限指南。

最终建议

如果你只想记住一条当前可执行的规则，那就记这个：

• 单次直接出图：先用 POST /v1/images/generations
• 已有素材要改图：先用 POST /v1/images/edits
• 图片生成只是更大多模态流程的一步：再用 Responses + image_generation
• 查路径看 reference，查新旧看 model catalog 与 GPT Image 1.5 页面

这条顺序比当前 page one 平均水平更有价值，因为它不是把官方事实再念一遍，而是把这些事实组织成一个真正能执行的接入决策。大多数排名页面仍然让读者自己在 reference、help center、旧例子和新 guide 之间拼答案。更稳的做法是：先把 surface 选对，先把第一条直接请求跑通，只有在产品真的需要时，再叠加更复杂的编排。

FAQ

普通图片编辑也要走 Responses 吗？

不用。对于常规 edit 工作流，当前 OpenAI 文档仍然支持直接走 POST /v1/images/edits 和 client.images.edit()。只有当图片编辑本身已经是更大会话式或 agent 式工作流中的一个节点时，Responses 才更合适。

为什么有些官方页面还在写 gpt-image-1？

因为当前文档还没有完全同步。按照 2026 年 3 月 23 日的官方状态，all-model catalog 和 GPT Image 1.5 model page 都把 GPT Image 1.5 作为当前图像主线；但 Images and vision 这类页面仍保留了旧表述。新接入时，不要把旧表述当默认。

明明接口写对了，为什么还是调用失败？

因为接口路径正确，不代表账户访问已经准备好。当前 GPT Image 1.5 模型页写明 Free 不支持，公开限额从 Tier 1 开始；帮助中心又说明部分图片访问还与组织验证相关。如果 endpoint 看起来没问题，但请求还是失败，优先检查 tier、组织验证和 active org，而不是先去改 prompt。