Using wan2.7-image/text-to-image for E-commerce Product Images via the HiAPI API

Why a text-to-image model belongs in your packshot workflow

Catalog teams rarely have a photography problem — they have a throughput problem. A single SKU needs a clean front packshot, sometimes angle variants, and often a marketplace-spec version. Real photography still wins for hero assets and anything that must be pixel-faithful to the physical product. Generated packshots solve a narrower, more practical set of cases: placeholder imagery for products awaiting a shoot, background variants for A/B tests on listing pages, concept renders during assortment planning, and consistent framing across long-tail SKUs that would never justify a studio slot.

The useful mental model is that generation sits between product data and the listing, not in place of the photographer. Your catalog already holds the structured facts — product name, material, color, form factor, packaging. A text-to-image model turns those facts into an image candidate. The pipeline question is how to do that repeatably, at catalog scale, without a human rewriting prompts for every SKU.

That is the problem this guide addresses. We will cover how to structure prompts so a catalog of products produces visually consistent packshots, how to diagnose prompt drift, when 4K output is actually worth it, and how to wrap the whole thing in a thin service so product code never talks to an image model directly. The model here is wan2.7-image/text-to-image on HiAPI, called through one unified API.

Setting up wan2.7-image/text-to-image on HiAPI

wan2.7-image/text-to-image is a text-to-image endpoint on HiAPI: you send a prompt payload, you get an image back. There is no separate account per model, no per-vendor SDK to install, and no need to manage a second set of credentials — HiAPI handles routing so your integration surface stays the same as you add or swap models.

The zero-to-first-render path looks like this:

Get an API key and confirm the model name

Create a key in your HiAPI account, then confirm the exact model identifier wan2.7-image/text-to-image in the model listing. Treat the identifier as configuration, not a hardcoded string — put it in an environment variable or config file so you can point at a different image model later without touching call sites.

Send a minimal request

The shape of the call is deliberately boring: a prompt, plus the model name. Start with a single sentence describing one product against a plain background and inspect what comes back. Do not build templates yet — first confirm that auth works, the response contains image data you can decode or fetch, and you understand what metadata (dimensions, format) the response carries.

Store the response as an artifact

Write the returned image to your object storage under a deterministic key rather than holding bytes in memory or in a database. From the first call onward, treat every render as an asset with a name, a prompt version, and a timestamp — retrofitting that later is painful.

Log the prompt alongside the image

The single most valuable piece of metadata is the exact prompt string that produced an accepted image. Log it. When a reviewer asks "why does this one look different," the prompt is the answer.

Anatomy of a packshot prompt

A packshot prompt that works once is an accident; one that works across a catalog is a structure. Use five components, always in the same order, so the only thing that changes between SKUs is the data you inject:

Subject

The concrete object, with its category and the one or two attributes that define its silhouette. "A matte ceramic pour-over coffee dripper" tells the model more than "a coffee maker." Name the product type, not the marketing name.

Material and finish

Surface behavior drives realism in product imagery. State the material and the finish explicitly: matte, brushed, glossy, frosted glass, uncoated paper, anodized metal. If the real product has a subtle texture, say so — this is where drift most often starts.

Lighting

Product packshots need predictable lighting. Pick a small vocabulary and stick to it across the catalog: soft even studio lighting, a single soft key light from the upper left, a gentle gradient falloff. Avoid dramatic language unless you want dramatic output; consistency beats artistry for listings.

Background

Specify plain and neutral, and specify the color: pure white seamless, light warm gray, transparent-looking neutral. Ambiguous backgrounds produce busy ones. If the marketplace requires white, say white.

Framing

State the crop and the camera position: centered, product occupying roughly two-thirds of the frame, straight-on eye-level view, slight three-quarter angle, nothing cropped. Framing is what makes a grid of SKUs look like a set instead of a grab bag.

A template built from these five slots lets you generate a whole category from a table of structured product rows, and it makes the next section — fixing drift — a matter of editing one slot at a time.

Improving prompt adherence

When a render drifts from the product description, the instinct is to rewrite the prompt. Resist it. The productive move is to identify which component failed and change only that, one variable per iteration.

Diagnose before you rewrite

Compare the render against your five slots. Is the material wrong but the framing right? Then only the material sentence needs work. Is the product correct but floating in a cluttered scene? The background clause is too weak. Naming the failing slot turns a vague "it's not quite right" into a specific edit.

State constraints explicitly, including negatives

Models respond to what you say, so say the important things out loud. If the product must not have a visible logo, an unsightly reflection, or a hand holding it, write those exclusions into the prompt. Explicit constraints reduce the space of plausible renders, which is exactly what adherence means.

Reduce the number of ideas per prompt

Every additional element — props, shadows of other objects, decorative surfaces — competes for the model's attention. For packshots, cut props entirely. A prompt that describes one object in one setting adheres far more reliably than one that also requests a styled scene.

Keep a small test set and a fixed seed of comparison

Pick five representative SKUs across your catalog — one hard material, one reflective, one small, one large, one with printed packaging. When you change a template, re-render all five and compare. This catches the common failure where a fix for one product type quietly breaks another. Log the template version with every render so you can attribute a change in output quality to a change in prompt.

Escalate to structure, not adjectives

If a slot keeps failing, the fix is usually more structure, not more adjectives. Replace "beautiful studio lighting" with the specific setup you want. Replace "nice background" with a color and a surface. Adherence improves when the prompt reads like a spec sheet, not a wish.

Working with 4K output

Higher resolution is a placement decision, not a default. wan2.7-image/text-to-image supports high-resolution output, but every 4K render costs more time, more storage, and more downstream processing than a standard render. Treat the choice as a routing rule keyed to where the image will appear.

Map resolution to use case

Hero images on a product detail page and any image intended for zoom deserve the highest tier — that is where shoppers inspect stitching, texture, and labeling. Grid thumbnails, category tiles, and search results do not; generating them at 4K and downscaling is waste. Marketplace spec sheets often publish their own minimum dimensions, so the marketplace requirement, not the model's maximum, should set the floor. Everything else — internal review renders, A/B test variants, placeholder imagery — belongs at a standard tier.

Plan for the asset, not just the request

A 4K image is a large file. Decide up front whether you store the full-resolution original and derive smaller variants at delivery time, or store only the tier each placement needs. Storing originals plus generated derivatives is usually simpler to reason about and lets you re-render delivery sizes without calling the model again. Budget storage and CDN egress accordingly, and make sure your asset naming encodes the resolution tier so a downstream service cannot accidentally serve a 4K original into a thumbnail slot.

Render high-resolution late

During prompt iteration, render at standard resolution. Adherence problems are visible at any size, and iterating at 4K multiplies your cycle time for no diagnostic benefit. Promote to high resolution only after a prompt variant is approved — one high-resolution render per approved asset, not per experiment.

Making the API call in a product pipeline

The call itself is one line of logic. The work is keeping it out of your product code. Wrap it in a thin internal service with four responsibilities:

Prompt templates as versioned data

Store the five-slot template outside the application, keyed by category. The service takes structured product data, fills the slots, and records which template version produced the render. When you edit the template, old assets still trace back to the version that made them.

A generation function with explicit inputs and outputs

The service exposes something like generatePackshot(productId, category, options) and returns an asset reference — not raw bytes. Options include resolution tier and template version. Everything about the HiAPI call — auth, model identifier, request shape — lives inside this boundary. If you later change the model string or add another image model, product code does not change. The same applies to teams using HiAPI for other modalities: one integration pattern, one set of credentials.

Retries with a bounded budget

Generation is a network call to a remote model. Retry transient failures, but cap the attempts and use jittered backoff. More importantly, distinguish retryable failures from requests that will never succeed — a malformed template should fail fast and loudly, not burn your retry budget. Record the attempt count on the asset so you can see how often renders need a second try.

Predictable asset naming

Name assets from data you already have: product ID, category, template version, resolution tier, and a short content hash. Deterministic names make idempotency possible — a retried job that already produced an asset can skip regeneration — and they make it trivial to find every render of a given SKU.

Keep the service stateless. Queue jobs, process them, write assets, emit an event. That way a catalog-wide backfill and a single-product request use the same path.

Quality checks before images reach the storefront

A generated image should pass through gates, in order, before anything publishes. Automate the cheap checks; reserve human review for the judgment calls.

Gate 1: Technical validity

The file must decode, match the expected format, and be at least the resolution tier requested. Reject anything undersized or corrupt before it enters storage. This gate is fully automated and should never fail silently.

Gate 2: Listing requirement compliance

Check the image against the real rules of the destination: minimum dimensions, aspect ratio, background color tolerance if white is required, and file size limits. Encode marketplace specs as data so a spec change is a config change. This is the gate that catches the most embarrassing failures — a beautiful render that a marketplace rejects on dimensions.

Gate 3: Content sanity

Automated checks here are weaker, but cheap heuristics help: confirm the image is not blank or near-uniform, that the dominant background matches the requested color, and that the subject occupies a plausible share of the frame. Route failures to a review queue rather than discarding them; a heuristic miss should cost a human glance, not a lost asset.

Gate 4: Human spot check

Sample a percentage of renders per template version and per category for human review, and review 100% of a new template's first batch. When a template is approved, drop to sampling. Reviewers should see the image, the prompt, and the product record side by side — that context is what makes the check fast.

Only after all four gates does an asset get marked publishable. Store the gate results with the asset so audits do not require re-running checks.

Where to start this week

Pick one category with at least a dozen SKUs and one placement that tolerates generated imagery. Write the five-slot template for that category, build the thin generation service around wan2.7-image/text-to-image on HiAPI, and run the whole category through it at standard resolution. Put the outputs through the four gates manually before you automate any of them — you will learn more from reviewing that first batch than from any amount of prompt theory.

Once a template survives a catalog pass with acceptable adherence, version it, wire in the automated gates, and only then decide which placements earn high-resolution renders.