Company image operations
Saved image operations, scoped downloads and unknown-outcome handling.
No current prepared translation is available. The English source is shown without machine translation.
Company image operation handling
Record the returned operation ID alongside your business job ID and Idempotency-Key. Reads use the same active company API key that created the operation; owner membership alone does not grant access to other principals' images.
| Method | Path | Purpose |
|---|---|---|
| GET | /v1/images/operations | Up to 50 scoped operations; use the returned next_cursor as before |
| GET | /v1/images/operations/{id} | Persisted status, price/usage information and file descriptors |
| GET | /v1/images/operations/{id}/result | Completed image envelope or pending/terminal state |
| GET | /v1/images/operations/{id}/files/{index} | Authenticated output download, zero-based index |
| POST | /v1/images/operations/{id}/retry-downloads | Empty-body request to retry only stored-result downloads |
queued and preparing precede dispatch. A paid POST starts only after the durable dispatching boundary. received and retrieving mean that response handling can resume without sending another generation. completed has available outputs until expiry. failed and expired are terminal.
Treat outcome_unknown and review_required as an operator incident. These states do not prove either free failure or successful billing. There is no automated reconciliation mutation in this release. Never blindly issue a fresh idempotency key. retrieval_failed permits at most five explicit download retries within the 24-hour file lifetime; it neither regenerates nor creates another accounting entry.
The original principal, credential version and group are checked before dispatch; credentials and access policy are rechecked for reads. Legacy browser session keys remain foreground-only. Since10.49.0 the separate Playground Images tab uses narrow operation-scoped mg_image_ permissions; it does not expand the legacy key scopes.
accounting_recorded is an exactly-once canonical accounting fence, not proof of settled company balance. Actual token usage is required for token-based tariffs. A hard model_gate.max_cost_usd string ceiling is accepted only when a fixed quote is known. Limits and routing remain those currently configured for the company.
Playground and lost HTTP responses (10.49.0)
Playground Images uses separate read/create/download-retry grants with current actor/key permissions. It does not relax legacy browser-key restrictions. A stored operation can continue after its short grant expires, while current session, key and access requirements still apply.
GET /v1/images/operations?idempotency_key=... is a read-only lookup under the same identity/key scope. A matching operation returns its saved public status; no visible match returns submission_found:false. This is not a signal to automatically create another intent: the original acceptance may still be in progress. Use the same key/intent and inspect history. No token, body, price or debit is created by lookup.
Read-only GET /v1/images/catalog?model=...&operation=... exposes separate reviewed route offers, not a guarantee of provider health. POST /v1/images/quote normalizes supported settings and supplies an uncharged approval fingerprint. The index and direct creation endpoints remain available to ordinary API clients.
Catalog and saved fields
Use a company-visible model query for catalog discovery; operation defaults to generation and can be changed to image.edit. The list contains independent route offers and runtime limits. Its health flag is always false because a local configuration lookup does not test the supplier. An empty result can follow a missing review, expired evidence, key/route eligibility or an effective Only policy.
Saved state exposes the operation identity, model, status/error, creation and file-expiry Unix timestamps, quote/usage, file descriptors and read/retry URLs. Treat accounting_recorded with its accompanying note, not as a settled company balance. files_available describes the retention window, while the actual files list determines what has been obtained. Descriptors include the hash and dimensions required for private preview. No source uploads are published through result-file routes.
History is ordered by descending operation ID, at most 50 entries; it is not a chronological sort of externally supplied IDs. before cannot be combined with idempotency_key. The lookup response is a list with zero or one item and submission_found; not found is not proof that an in-flight create was rejected. Foreign resources are not disclosed.
In company operation details and history, quoted amounts remain explicitly labelled until measured accounting is recorded. Calculated cost does not by itself confirm company settlement. An empty file list during processing is not an expired download. For the separate aggregate-only usage representation and price labels, see image result fields.
Project accounting observation fields
The operation detail and same-intent lookup expose settlement only within the current billing owner, employee/principal, project key and group scope. record_found says whether its matching retained input was observed; settled_at and observed_at are Unix timestamps. wallet_debited and usage_applied remain null until supported by the recorded event, rather than treating missing evidence as false.
The status values distinguish not_recorded, unobserved not_checked list rows, pending, delayed failed, not_required, settled/recovered, absent not_available, and read-error unavailable. An observed settled/recovered timestamp with positive cost supports a debit label; zero-cost/Usage-Limit-only treatment is separate. This field does not perform settlement, report later refunds or reveal the company's current balance. After retention, the absence of a matching row is not proof of no expense. Read the particular operation to refresh an unobserved history row.
The added supplier_http_status (0 when unknown) and response_saved describe the saved supplier response, not the status of this read or the service's creation acknowledgement. A202/queued response is not evidence of supplier success. Retain the existing no-automatic-repeat handling of an unknown paid result.
Compact status and accounting details
Since version11.0.0, operation responses are compact by default: object, id, model, status, created, status_url, result_url. An actionable error_code or reported progress is included only when present. Completed results include availability, expiry and required file descriptors. Empty fields, quote, normalized usage, settlement and supplier diagnostics are omitted. Omission does not mean zero cost or a completed debit.
Use GET /v1/images/operations/{id}?view=details for the previous full authorized accounting view. Lists and result manifests also support the explicit details view where applicable. Reading details never generates new media or expands access. The quote endpoint remains the separate place to inspect an uncharged price calculation.
Read a result: Raw and cURL
Use the same active company key and employee/actor context that created the operation. A shared project key, company ownership or access to company billing does not grant another employee's result. Current membership and project/key permissions are checked again. Get OPERATION_ID from the accepted creation response or your authorized history, and set MODEL_API_KEY locally without publishing the secret. A temporary Playground permission is not a reusable CLI credential; copying a command does not export or enlarge that permission.
GET https://api.b2b-llm.com/v1/images/operations/{id}/result
Authorization: Bearer <YOUR_API_KEY>
# status
curl --fail-with-body --request GET \
--url "https://api.b2b-llm.com/v1/images/operations/${OPERATION_ID:?Set OPERATION_ID}" \
--header "Authorization: Bearer ${MODEL_API_KEY:?Set MODEL_API_KEY}" \
--output images-status.json
# result
curl --fail-with-body --request GET \
--url "https://api.b2b-llm.com/v1/images/operations/${OPERATION_ID:?Set OPERATION_ID}/result" \
--header "Authorization: Bearer ${MODEL_API_KEY:?Set MODEL_API_KEY}" \
--output images-result.json
# first image (only when descriptor index 0 exists)
curl --fail-with-body --request GET \
--url "https://api.b2b-llm.com/v1/images/operations/${OPERATION_ID:?Set OPERATION_ID}/files/0" \
--header "Authorization: Bearer ${MODEL_API_KEY:?Set MODEL_API_KEY}" \
--output image-0.bin
/result returns the saved created/data JSON response. A file endpoint returns actual image bytes, not that JSON. Select an existing zero-based index from the operation's file descriptors and choose an extension matching its MIME type; the example uses .bin rather than guessing PNG. Playground supplies the matching extension for each available image.
These are bodyless GET requests: no Content-Type, Idempotency-Key, quote, route_id or max_cost_usd is needed. Read status until it reports completion, then read the result/file. Pending, failed, expired and unauthorized responses are not output files; --fail-with-body returns a nonzero exit status for HTTP errors but may still write their body to the output filename. Check the status and content type before treating a downloaded body as media. Do not repeat a paid POST because a GET failed.
Playground's Get the result · Raw / cURL block generates these commands for the selected operation and its original key. They are examples of a new read, not a recording of an earlier HTTP exchange. Copying or switching command tabs makes no network request. Opening history or a saved result still performs its normal authorized read; it does not generate, reserve or charge again.