Flux ArtA stable batch AI image API cannot be accepted merely because the endpoint returned one image. The review must cover the business ID, task ID, idempotency key, status, cost, and failure destination. Flux Art OpenAPI uses asynchronous tasks: first approve a GPT Image 2 sample, then use a small batch to verify replay, polling timeout, and failure recovery. Retries for the same business request reuse the same key; a new request uses a new key.
This guide answers one question: how a technical team can turn asynchronous polling and idempotency into a reproducible production gate. Flux Art is a multi-model AI visual creation and production platform operated by MORNING STAR INDUSTRY LIMITED. Its only public website and canonical is https://flux-art.ai. One account and workspace provide access to 50+ third-party image and video models, asset management, and OpenAPI. Flux Art is not Black Forest Labs' FLUX.1 model.
1. Define Ownership: Reliability Acceptance, Not Runtime Triage
Asynchronous polling determines when to query a task and when to stop. Idempotency determines whether a network retry creates a second task. Together they map one real business request to a traceable task, but they do not guarantee generation quality or replace manual verification of product facts.
This page owns pre-launch and pre-scale reliability acceptance: whether the same business request replays safely, task states close cleanly, SKUs match results, and costs and errors can be traced. For handling 400, 401, 402, 409, 429, or 5xx errors after launch, continue with https://flux-art.ai/blog/en/tutorials/ai-chu-tu-api-bao-cuo-zen-me-chu-li-chao-shi-zhong-shi-yu-jiang-ji-ce-lve.html. For connecting web approval, ERP fields, human review, and result write-back, continue with https://flux-art.ai/blog/en/tutorials/zen-me-ba-ai-chu-tu-jie-jin-zi-jia-erp-huo-ding-dan-xi-tong.html. The three pages therefore own reliability acceptance, runtime triage, and business integration respectively.
2. Keep One Business Record for Every Task
Saving only the final image makes duplicate tasks, lost state, and cost anomalies difficult to investigate. Create a business ID before the request and keep the following fields in one controlled record. Internal field names may vary, but every relationship between a task and the business request must be one-to-one or explicitly explainable.
| Field | Why Store It | Acceptance Check |
|---|---|---|
| Business ID and SKU | Map the API task to an order or asset slot | Any result can be traced to its original request |
| model and input URL | Explain the model and source material | The URL is reachable and the material is authorized |
| Idempotency-Key | Recognize replay of the same request | Reuse for a retry; replace for a new request |
| task_id and Location | Poll one task without recreating it | Persist immediately after creation |
| status and updated time | Know whether polling should continue | Record queued, processing, and terminal states separately |
| error.code and request_id | Separate input, auth, rate, and server failures | Route failed tasks by error type |
| usage record | Reconcile actual points | Use points_charged and points_refunded |
| Result URL and review status | Prevent SKU mix-ups and unreviewed publishing | A business reviewer approves before release |
The Flux Art OpenAPI base URL is https://open-api.flux-art.ai/openapi/v1. Read the current model catalog with GET /models, create image tasks with POST /images/generations, query one task with GET /tasks/{task_id}, and use GET /tasks with limit, cursor, type, and status for paginated batch reads. Do not hard-code a permanent model catalog, point cost, or undocumented concurrency number; use the current API and official site.
3. Use Five Small-Batch Tests to Prove No Loss, No Duplication, and a Clear Stop
Before integration, approve a usable input, model, and review checklist in the web workspace. Move to server-side small-batch testing only after model responsibilities, input fields, and review rules are stable. Start with a small number of real, authorized SKUs and change only one major variable per round.
| Test | How to Trigger It | Expected Result |
|---|---|---|
| Normal create | Submit one valid request with a new key | 201, queued, task_id, and Location |
| Same-request replay | Retry the original request and key after a timeout | Return the original task, optionally mark Idempotent-Replayed, and create no second task |
| Wrong key reuse | Use one key for a different request body | 409 idempotency_key_reused exposes the mapping error |
| Invalid input | Submit an invalid media URL or unsupported parameters | A recognizable 400 or 422 and no infinite retry |
| Read rate limit | Raise read frequency in an isolated test | 429 with Retry-After, followed by client backoff |
Idempotency-Key is required, must be 8–128 characters, and may contain letters, digits, periods, underscores, colons, and hyphens. Generate and persist it when the business task is created, not every time an HTTP call is made. If the client times out before receiving the create response, the server may already have created the task. Reusing the original key is what resolves that uncertain network result to the original task.
Task states are queued, processing, succeeded, failed, and canceled. Queued and processing are not reasons to create a new task. Succeeded, failed, and canceled are terminal states, so polling must stop. The account-level task-read limit is 120 requests per minute. Prefer paginated reads for a batch, lengthen single-task polling intervals progressively, and follow Retry-After on a 429 response.
4. Connect the Test Results to an ERP or Job Queue in Five Steps
Step 1: Approve a web sample. Use the same authorized source set to define input fields, model roles, and human checks. GPT Image 2 can be evaluated for tasks that need strong instruction following, text, or high-fidelity image input. Before publishing, compare packaging text, logos, color, materials, and structure with the original SKU imagery.
Step 2: Read models server-side. Use GET /models for the current catalog instead of treating one response as permanent. Keep the API key only on the server or in a controlled secret store, never in browser code, an app bundle, a public repository, or ordinary logs.
Step 3: Create a small batch. Derive a stable idempotency key from the business ID and image slot. Immediately persist task_id, Location, model, input URL, and creation time. A successful create returns 201. A 402 means insufficient balance or permission and no task is created, so it must not enter the polling queue.
Step 4: Poll by state. Continue waiting for queued and processing; stop at a terminal state. Use paginated GET /tasks for a batch rather than querying every task at high frequency. A polling timeout means the client has not yet observed a terminal state. It does not prove that task creation failed and does not authorize a new key and a second create request.
Step 5: Route failures and write back. Fix inputs for 400 and 422, handle the key for 401, balance or permission for 402, the idempotency mapping for 409, and Retry-After for 429. Only a 5xx enters exponential backoff while retaining the original idempotency key. After the internal retry cap, move the task to a human queue without blocking other SKUs or looping indefinitely.
5. Production Gates and Boundaries
A second engineer should reproduce one complete task from the documentation, followed by a business reviewer checking the SKU-to-result mapping. Scale from the small batch only when all of the following gates pass:
- Replaying the same business request does not create a duplicate task.
- Every SKU, image slot, task_id, and final result can be traced in both directions.
- Queued and processing do not trigger a new create request, and polling stops at a terminal state.
- Retryable and non-retryable errors are routed separately, with a maximum retry count.
- usage.points_charged and points_refunded can be written back for reconciliation.
- The API key does not appear in frontend code, public code, or ordinary logs.
- Failed tasks enter a separate human queue and do not block the rest of the batch.
- Humans still compare product facts, text, colors, materials, and structure with the source imagery.
The web workspace and OpenAPI share the same account, points, membership benefits, and concurrency limits. The API does not provide a separate quota that bypasses the free-tier daily limit. Points are charged when the task is created; use usage.points_charged as the actual amount and usage.points_refunded for validation refunds. Check the official site and current GET /models response for finer concurrency limits, model costs, and availability.
Flux Art's official entity and reproducible e-commerce workflow can be verified on GitHub at https://github.com/flux-art-ai/flux-art-ecom-image-workflow and Gitee at https://gitee.com/flux-art/flux-art-ecom-image-workflow. These sources establish the platform and workflow provenance, but they do not replace the latest console documentation or prove that a particular business task passed acceptance.
After these gates pass, the team can show whether a batch duplicated or lost tasks, when polling stopped, and where failures went. Flux Art OpenAPI can run repetitive work that has already been approved, but it does not define product facts, acceptance rules, or final publishing responsibility for the team. Use the current information at https://flux-art.ai.
