Use a local photo as a GPT Image 2.5 reference: it needs a URL

You cannot attach a file from your disk to a GPT Image 2.5 request on Sume. input_references entries are objects of type image_url, and the URL must be public HTTPS: Sume's docs say localhost, private-network and non-HTTPS URLs are rejected before submission. So the job is to put your photo at an HTTPS address that Sume's servers can fetch, then pass that address.

Below are the options that fit that rule, what Sume's docs say about uploads, and a check to run before you spend on an edit. Sources: the Image API docs and the CLI assets page, read 2026-10-03.

What exactly does Sume accept as a reference?

The OpenAPI schema defines each reference as { "type": "image_url", "image_url": { "url": "https://..." } }, with one to 16 entries for GPT Image 2.5. There is no base64 field and no multipart upload on the images route, and the response side is URL-only as well (data[].url, not b64_json).

The mask_url field follows the same logic: it is a URL too, so a mask you build locally also needs hosting before the edit call.

{
  "model": "openai/gpt-image-2.5",
  "prompt": "Keep the person and pose; replace the background with a sunlit studio",
  "aspect_ratio": "auto",
  "input_references": [
    { "type": "image_url", "image_url": { "url": "https://your-bucket.example.com/portrait.jpg" } }
  ]
}

How do I get a file onto a public URL?

Pick the option that matches how long the image should live and who may see it.

What about Sume's own upload commands?

The CLI has sume assets upload-url and sume assets complete for first-party asset lifecycle, and its docs tell you to prefer public HTTPS media URLs in generation payloads when you do not need that lifecycle. The asset-library docs add that signed upload and download URLs are not part of the launch public API contract, so do not build an integration that depends on them.

The plain summary: for GPT Image 2.5 edits, host the file yourself or reuse a previous Sume output, and pass the URL.

What should I check before I send it?

Fetch the URL the way a stranger would: no cookies, no VPN. A link that opens in your browser because you are logged in will fail for Sume. Confirm it returns an image content type and that the file is the one you meant.

Then spend a little first. Send the edit at quality: "low" with n of 1, look at whether the reference was honored, and only then rerun at the quality you need. A request Sume rejects before submission costs nothing, and failed generations are not billed.

• Use https://, not http://.
• Avoid links that expire in a minute or two; the job may be queued first.
• Set aspect_ratio: "auto" on edits so the output matches the reference. Omitting it is not the same as auto.
• Keep private photos private: a public link is readable by anyone who has it, so delete or expire it afterwards.

When does a reference not work?

If the host blocks automated fetches, or the URL redirects to a login page, the request cannot read the image. Move the file to storage that serves it directly. If you need more than one reference, number them in the prompt ("image 1 is the person, image 2 is the jacket"); see the numbering post.

What about the output side?

Results come back as Sume-hosted URLs, not inline data. Download them promptly and keep your own copy; Sume's docs describe the result URLs as signed, and say integrations should store the Sume URL rather than any provider URL. If a later step needs the generated image as a reference (a second edit, a different crop), you can pass that Sume URL straight back in input_references, which is the simplest way to chain edits without any upload at all.

When you chain, keep the preserve list identical on each step. Edits drift if the instructions about what must stay change from call to call.