Seedream image URL expired after 24 hours: use the Sume copy
BytePlus keeps Seedream image URLs for 24 hours, then clears them. On Sume, read data[].url or the job result URL and store that, not a provider link.

A Seedream image URL from BytePlus stops working after 24 hours because BytePlus clears it: its Seedream 5.0 overview says generated image URLs are retained for 24 hours, then cleared, and tells you to download results you want to keep. If you call Seedream through Sume, you read a Sume-hosted URL from data[].url instead, and you should store that.
Vendor facts are from BytePlus, read 2026-09-30. Sume facts are from the Image API docs and Jobs and results.
What does BytePlus say about the 24 hours?
Under operational notes, the overview states: "Generated image URLs are retained for 24 hours, then cleared." The same notes say rate limiting is per minute and recommend keeping the SDK current. Nothing on the page describes a way to extend the window, so treat the link as temporary.
Which URL does Sume give me for a Seedream image?
POST /v1/images returns data[].url, described as Sume-hosted and signed, rather than inline base64. The docs say Sume already mirrors generated media. The catalog lists Seedream ids such as seedream-5-lite; the public model value in the docs' request examples looks like bytedance-seed/seedream-4.5. The docs do not state how long a Sume URL stays valid, so do not assume it is permanent either.
If the call takes longer than the 30-second wait it returns 202 with a job envelope. Then poll GET /v1/jobs/{id}/status and read GET /v1/jobs/{id}/result, and use the Sume media URLs from that result.
| Question | BytePlus direct | Sume `/v1/images` |
|---|---|---|
| Link in the response | Generated image URL | data[].url, Sume-hosted, signed |
| Documented lifetime | 24 hours, then cleared | Not documented |
| Long calls | Not covered by this page | 202 job, then GET /v1/jobs/{id}/result |
What should I store?
Download the bytes as soon as the job completes and write them to your own storage, then keep your storage key. Keep the Sume job id too, so you can re-read the result. Do not store a provider link; the Sume docs say raw provider URLs are not public API outputs. For the same pattern on another model, see FLUX image URL expires after 10 minutes.
What if my old link already returned an error?
A cleared provider URL cannot be revived from your side. If you still have the Sume job id, read the job result again and use the URL it returns; if you have neither the file nor the id, you need to generate again.
Sources
Related posts
More in Developers
- Create vs read rate limits: Managed Agents 300/1,200, Sume plans
Anthropic's Managed Agents limit creates and reads separately. Sume splits its per-minute budget the same way by plan, so polling cannot starve submits.
- SNS 1 MiB messages and Sume run webhook fan-out
Sume run webhook bodies are capped at 1 MiB, and SNS now allows 1 MiB messages with MaximumMessageSize. Ack the webhook first, then publish.
- Sora download URL expired after 1 hour: what Sume returns
Sora download URLs were valid for at most 1 hour. Sume returns unsigned_urls on completion and serves the file from GET /v1/videos/{jobId}/content.
- Sora input image must match size: the Sume frame_images rule
Sora's input image was the first frame and had to match the video size. Sume uses frame_images plus aspect_ratio, and rejects size on v1 models.
Written by Sume