Async Image Generation Support Notice

GPT88 now documents an asynchronous image-generation workflow: submit a task, persist its ID, poll the task, and download the final image without holding the original request open.

Release date

Published on August 5, 2026. This notice describes the documented client workflow and keeps dynamic model limits, pricing, and exact response fields subject to the live API response.

What changed

Image generation can now be integrated as a background task. Your server does not need to keep the original HTTP request open until the image is ready. Instead, it records the task ID and checks the task state later.

Before	Async workflow	Why it matters
Wait for the image in one request	Return after the task is accepted	Avoid gateway, proxy, and serverless timeout pressure.
Treat every response as final image data	Handle accepted, processing, succeeded, and failed states	Prevent a task object from being mistaken for an image.
Retry the whole request after a timeout	Resume polling when a task ID already exists	Reduce duplicate generations and accidental extra usage.
Download immediately from the response	Download after the task reaches a terminal state	Keep result handling separate from task orchestration.

Entry points

async-image-endpointstext

Async image entry points
  Submit: POST https://img.gpt88.cc/v1/images/generations
  Poll:   GET  https://img.gpt88.cc/v1/images/generations/{task_id}
  Result: data[0].url or data[0].b64_json, depending on the response

POSThttps://img.gpt88.cc/v1/images/generations

GEThttps://img.gpt88.cc/v1/images/generations/{task_id}

The submit request uses the image-generation endpoint. The asynchronous option and task response shape can vary by model or rollout; the detailed guide shows a compatibility-first parser instead of assuming one fixed JSON envelope.

When to use async generation

Scenario	Recommendation	Trade-off
One small preview and an interactive UI	Start with synchronous generation	Simpler, but the UI must handle a longer request.
High-resolution cover, poster, or hero image	Prefer async generation	More state handling, but better timeout resilience.
Batch image jobs	Use async generation plus a durable task table	You must manage concurrency, retries, and result retention.
Editing with large reference uploads	Prefer async when the client timeout is short	The task may be accepted before the final asset is available.
A worker queue or scheduled pipeline	Use async as the default boundary	Polling adds API calls and needs a clear stop policy.

Compatibility and response fields

The stable concept is the task lifecycle, not a single vendor-specific JSON shape. Your client should accept a task identifier from task_id or id, read status from the top level or a nesteddata object, and look for the final URL or base64 payload in the result object.

lifecycle-shapes.jsonjson

// Illustrative compatibility shapes. Check the live response for your model.
{ "task_id": "imgtask_123", "status": "queued" }
{ "data": { "task_id": "imgtask_123", "status": "processing", "progress": 42 } }
{ "data": { "task_id": "imgtask_123", "status": "succeeded", "result_url": "https://.../image.png" } }
{ "data": { "task_id": "imgtask_123", "status": "failed", "error": { "message": "..." } }}

Migration checklist

Keep your existing synchronous call as the small-preview path.
Add an async submit path and persist task_id, model, prompt hash, and submission time.
Implement polling with a bounded interval and maximum duration.
Handle success, failure, cancellation, timeout, HTTP errors, and malformed responses separately.
Download or persist the image as soon as a result URL appears; do not treat a temporary URL as permanent storage.
Compare actual usage in the console before increasing concurrency or batch size.

Important notes

Keep API keys on your server or worker. Do not expose them in browser JavaScript or a public repository.
If a submit request returns a task ID, do not blindly submit the same prompt again after a client-side timeout.
If polling receives a temporary network or rate-limit error, back off and resume with the same task ID.
Failed, retried, async, image, and video accounting can have different behavior. Verify usage details instead of assuming a refund.
For the complete cURL, Node.js, Python, troubleshooting, and production checklist, read the Async Image Generation Guide.
For synchronous image request fields, see the Image Generation API reference.