Generating E-commerce Product Images with gpt-image-2/text-to-image via the HiAPI API

Why use text-to-image for e-commerce product visuals

Product imagery is one of the biggest bottlenecks in a catalog pipeline. A single SKU often needs a clean listing shot, a lifestyle context image, a banner crop, and several social variants — and every one of them has to be re-shot or re-edited when the packaging changes. Text-to-image models give developer teams a programmatic way to fill those slots from data you already have.

The realistic use cases are worth separating from the unrealistic ones:

• Supplementary variants. Generate lifestyle, seasonal, or contextual backgrounds around a product you already have a reference shot for, instead of scheduling a studio session for every placement.
• Catalog scaffolding. Produce draft imagery early in a launch so merchandising and marketing can review layout and crop before final assets land.
• Localization and personalization. Swap settings, seasons, or styling through prompt variables while keeping the product description fixed.
• Placeholder and testing fixtures. Generate deterministic frame-filling images for staging environments, so your storefront templates are exercised with real-looking content.

What text-to-image does not replace is the authoritative product record. Generated visuals should never invent features, materials, colors, or accessories that the actual product does not have. Treat the model as a rendering layer over product data, not as a source of truth about the product. If a generated image shows a finish or a component that isn't real, that's a defect, not a creative flourish.

The rest of this guide assumes that framing: your product data and existing reference photography stay the source of truth, and the model produces the contextual and compositional layers around it. With that boundary in place, the API integration question becomes straightforward — one request template, a set of prompt variables per SKU, and an output you can validate.

How gpt-image-2/text-to-image fits the HiAPI workflow

On HiAPI, gpt-image-2/text-to-image is a single model endpoint behind the same unified API surface you use for other generations. You don't need a separate vendor integration, a separate credential store, or a different SDK per modality — your application sends a request to HiAPI and receives the generated image in the response.

The minimum mental model is three pieces:

The request

A text-to-image request carries your prompt and the parameters that control the frame, most importantly the aspect ratio. Everything the model knows about the desired output comes from that prompt, so the prompt is the real interface — parameterizing it cleanly is the engineering work.

The model identifier

You address the model by name in the request: gpt-image-2/text-to-image. Keeping the model identifier as a configuration value rather than a hard-coded literal makes it easy to swap or A/B test later without touching call sites.

The response

The call returns generated image data. How you handle it — writing to object storage, streaming to a worker, or returning a temporary URL — depends on your pipeline, but the shape of the integration stays constant: build a request, send it, persist the result, record the metadata.

Before writing code, decide three things: where prompts will live (a template with variables, not string concatenation scattered across the codebase), where outputs will be stored, and what your validation step looks like. Teams that skip the third item end up manually reviewing every generated image, which defeats the purpose of automating generation in the first place.

Designing prompts for product-accurate output

Consistent catalog imagery comes from consistent prompt structure. Instead of writing a fresh sentence per SKU, define a template with fixed slots and swap only the values that legitimately differ. A structure that holds up well for product work has five parts, in this order:

1. Subject

State what the product is, plainly and specifically: the category, the form factor, and any material or finish that is actually true of the product. Pull these values from your product record rather than paraphrasing by hand — that's what keeps SKUs comparable.

2. Setting

Describe the environment the product sits in: a plain studio sweep, a kitchen counter, an outdoor surface. The setting is where most of the variation across a catalog should come from, because it's cheap to change and doesn't risk misrepresenting the product.

3. Lighting

Specify the light: soft diffused daylight, directional studio key with a fill, warm interior light. Lighting has an outsized effect on perceived quality and is one of the easiest things to standardize across a catalog for visual coherence.

4. Composition

Say where the product sits in the frame, at what relative scale, and from what angle. Front-facing centered, three-quarter view, close crop on the top surface. This is where you encode the storefront layout requirements covered in the next section.

5. Style

Close with the rendering intent: clean commercial product photography, minimal editorial styling, soft neutral palette. Keep style descriptors short and consistent across a batch.

A few practical rules that prevent most bad outputs:

• Don't add details the product doesn't have. No invented logos, extra buttons, or accessories. If a detail isn't in your product data, it shouldn't be in the prompt.
• Keep negatives explicit but brief. "No text overlays, no additional objects, no reflections of people" is more reliable than a long list of prohibitions.
• Fix the template, vary the variables. If every SKU has a differently-worded prompt, your outputs will vary for reasons you can't debug.
• Version your templates. Store the template version alongside each generated asset so you can trace an output back to the prompt that produced it.

A minimal template looks like this, with the bracketed slots filled from product data:

[product description], [setting], [lighting],
[composition and angle], [style descriptors],
no text overlays, no additional objects

Choosing aspect ratios for storefront layouts

Pick the aspect ratio from the placement, not the other way around. If you generate a square image and then crop it into a wide banner, you've thrown away control over composition — the model framed the subject for a square, and the crop decides the rest. Generating at the target ratio lets the composition instructions in your prompt actually do their job.

Map your storefront's image slots first, then assign ratios:

Square (1:1)

The default for product grid tiles, marketplace listings, and anywhere the layout is a uniform card grid. Centered, front-facing compositions work best here because the frame is symmetric and crops in lazy-loading contexts tend to be minimal.

Portrait (4:5, 2:3)

Common for primary product detail images, mobile-first feeds, and lookbook-style layouts. Portrait frames give vertical products room to breathe and leave space above or below the subject for merchandising elements your frontend overlays.

Landscape (16:9, 3:2)

Category banners, hero slots, email headers, and collection covers. Landscape frames suit scenes more than single objects — a product in context with room on one side reads better than a centered object in a wide empty frame.

Tall and narrow (9:16, 4:5 story)

Story formats and vertical promotional placements. Composition here should be explicitly vertical: subject low or centered, significant headroom, no wide horizontal elements.

Two workflow notes. First, generate per placement rather than resizing one master image into every slot — the prompt's composition clause should change with the ratio, which means separate requests. Second, keep a canonical square or portrait master per SKU for archival and for placements you haven't enumerated yet, and treat the derived ratios as regenerable outputs rather than assets to preserve.

Once your slot-to-ratio table exists, it belongs in configuration next to the prompt templates. Merchandising changes a layout, you change one value, and the next generation for that placement uses the new frame — no code change required.

A working text-to-image request through HiAPI

With templates and ratios defined, the request itself is mechanical. The workflow below is the one to build once and reuse per SKU.

Step 1 — Assemble the prompt

Load the template, fill the subject slot from the product record, and fill the setting, lighting, composition, and style slots from the placement configuration for the target slot. Record the template version and the variable values alongside the request so the output is reproducible.

Step 2 — Set the frame

Pass the aspect ratio that corresponds to the target placement. Composition wording in the prompt and the ratio should agree — a "centered product, generous headroom" clause in a 16:9 frame will produce a different result than the same clause in 4:5.

Step 3 — Send the request

Send a text-to-image request to the gpt-image-2/text-to-image model through the HiAPI API, authenticated with your HiAPI credential. Keep the model identifier, ratio, and prompt template as configuration inputs so the same code path serves every SKU and placement.

POST to the HiAPI image generation endpoint
  model:  gpt-image-2/text-to-image
  prompt: <assembled template>
  aspect_ratio: <ratio for target placement>

Refer to the HiAPI documentation for the exact endpoint path, authentication header format, and parameter names before wiring this into your service — those details are the contract, and copying them from a blog post is how integrations drift.

Step 4 — Handle the response

Receive the generated image, then persist it immediately. Write the binary to your object storage under a key that encodes SKU, placement, and template version, and record a row in your asset table with the request metadata: prompt text, ratio, model, and timestamp. Doing this inside the request handler rather than in a side job keeps the asset and its provenance together.

Step 5 — Gate the output

Route the generated image through a review step before it reaches the storefront. At minimum: does the product match the record, is the frame the requested ratio, and are there no invented details or text artifacts. Automate what you can (ratio checks, basic image sanity) and queue the rest for human review during early runs.

Step 6 — Return a reference

Hand the storefront a stable storage key or URL, not the raw response payload. Your frontend shouldn't know or care that the image came from a generation request; it should see the same asset contract as any other catalog image.

Scaling generation across a product catalog

One working request is a demo; a catalog pipeline is a queue. The shift from the former to the latter is mostly about isolation and observability.

Make each SKU a job

Wrap the request workflow in a job with explicit inputs — SKU, placement, template version — and explicit outputs — stored asset key, status, request metadata. A job that fails for one SKU should not stall the batch. Retries should be safe: because each run is parameterized, re-running a failed job produces a comparable result rather than a duplicate mystery asset.

Separate prompt authoring from execution

Prompt templates and slot-to-ratio mappings should be data, versioned and reviewed, not code buried in a worker. This lets merchandising and marketing iterate on wording and framing without a deploy, and it lets you compare template versions against the same set of SKUs when output quality shifts.

Budget and rate discipline

Generation cost scales with volume, so track how many requests each batch issues and make placement selection deliberate — don't generate every ratio for every SKU by default. Billing follows the usage of the generation endpoint, and the current rates live on the pricing panel in your HiAPI account rather than in this guide. A dry-run mode that assembles and logs prompts without sending them is worth building early; it catches template errors before they cost anything.

Audit what you generate

Keep the request metadata attached to every asset permanently. When a merchandiser asks why a product looks off in one placement, you want to pull up the exact prompt, ratio, and template version in one query rather than reconstruct it from logs.

Define acceptance criteria up front

Decide what "good enough for the storefront" means before you generate at volume: product fidelity against the record, correct frame, no spurious text, consistent lighting within a batch. Encode the automatable checks, and treat the human review queue as a shrinking step rather than a permanent tax.

Get the template, the ratio mapping, and the job wrapper right, and scaling to a full catalog is throughput work rather than redesign work. Start with one SKU and one placement, confirm the request workflow end to end, then expand the job across your catalog.