Background removal is rarely the whole product-photo job. In an ecommerce catalog, the real job starts when an image arrives from a supplier, photographer, merchant, or marketplace export and ends when the correct asset is attached to the correct SKU in the correct order. The cutout in the middle can be excellent and the workflow can still be a complete mess.
I think about automation as a controlled asset pipeline, not a button that happens to run unattended. The pipeline needs to preserve the source, carry product identity through every step, create channel-ready derivatives, and stop when an image looks risky. If it cannot explain what happened to SKU CHAIR-OAK-02, it is not production automation yet. It is a demo with excellent confidence.
This guide lays out the version I would build for a growing catalog team: a durable intake record, deterministic file names, queued processing, visible review states, and a publish step that can be reversed. The exact storage provider and commerce platform can change. Those boundaries should not.
The useful mental model
Automate the route through the catalog, not just the pixels.
- Keep an immutable original and create new derivatives beside it.
- Use product and variant IDs as data, never as guesses extracted from a filename at the last second.
- Send ordinary images straight through and route uncertain outputs to review.
- Publish only after storage, validation, and catalog attachment have all succeeded.
- Make replacement reversible until the team trusts the pipeline.
01
Map the asset route before choosing tools
Start by drawing the path one product image takes today. It may arrive in a shared drive, an SFTP drop, a PIM, a CSV attachment, or a folder named FINAL_final_USE_THIS_4. Write down where product identity enters the process, who approves the image, which system owns the original, and where the published URL is stored. The awkward manual steps are not noise. They are requirements wearing a trench coat.
The most important split is between processing and publishing. Processing creates a candidate asset. Publishing changes what a customer or downstream channel sees. Those should be separate states and usually separate permissions. A transient API failure should not disturb the live catalog, and a beautiful processed image should not go live if its variant mapping is ambiguous.
What must arrive with the image
Require a stable source ID, product or SKU ID, variant identity when relevant, source URL or object key, and an ingestion timestamp. A filename can be useful evidence, but it should not be the database.
What the pipeline promises
Define format, canvas, crop behavior, background, color profile, output dimensions, storage key, review status, and the catalog destination. “Clean it up” is not an output contract.
02
Keep the original immutable
Never make the first automated action “replace the source image.” Store the incoming file under an immutable key and write its byte size, MIME type, pixel dimensions, checksum, and source system to the job record. If a supplier sends a corrected photo tomorrow, that is a new source version, not an invitation to rewrite history without an audit trail.
A predictable object layout
catalog/SKU-1842/sources/2026-06-18T142233Z-original.jpg
catalog/SKU-1842/jobs/job_7ff2/input.json
catalog/SKU-1842/masters/job_7ff2-transparent.png
catalog/SKU-1842/derivatives/job_7ff2-white-2000.jpg
catalog/SKU-1842/derivatives/job_7ff2-card-1200.webp
catalog/SKU-1842/review/job_7ff2.jsonThat layout is intentionally unglamorous. It lets support compare the exact input and output, lets a worker retry without inventing another filename, and lets the business regenerate derivatives when a marketplace changes its rules. Originals are expensive to reacquire. White-background JPEGs are not. Set retention accordingly.
Do not process a storefront thumbnail by accident
Commerce platforms often expose several resized or compressed URLs for the same photo. Feed the highest-quality permitted source into background removal, then create smaller derivatives afterward. Enlarging a 320-pixel thumbnail into a 2,000-pixel listing image is technically automation, just not the kind anyone puts in the quarterly update.
03
Give every image a durable processing state
A queue is useful, but the job record is the real center of the system. It should tell the UI and operators whether an image is waiting, running, ready for review, approved, published, or failed. I prefer explicit states over a pile of nullable timestamps because a state machine makes illegal transitions obvious.
received → validated
Decode the file, enforce byte and pixel limits, confirm the product reference exists, and reject HTML error pages pretending to be JPEGs.
queued → processing
Lease the job to one worker, record attempt count and processor request ID, and use bounded concurrency. Catalog imports have a habit of becoming traffic tests without asking permission.
processed → review or approved
Store the output first, validate that it decodes, then evaluate risk signals. The API response is not durable until your storage write succeeds.
approved → published
Attach the derivative to the intended product and variant, verify the returned media ID or URL, and only then mark the job published.
Make processing idempotent. A stable key such as source checksum + normalized recipe version can identify equivalent work. If a worker times out after storing the PNG but before updating the database, the retry should find that PNG and continue. It should not bill for the same work again, create five duplicate gallery images, or begin a small philosophical debate about which output is canonical.
Store enough evidence to debug one image
- Source checksum, dimensions, content type, and original object key
- Product ID, SKU, variant IDs, and the mapping rule that selected them
- Normalized processing options and recipe version
- Attempt count, response status, request ID, and timing
- Output checksum, dimensions, content type, and storage key
- Reviewer, decision, publish target, and previous live media ID
04
Automate the easy majority and review the weird minority
The goal is not zero human review. The goal is to spend human attention where it changes the outcome. A centered ceramic mug on a contrasting background can usually pass automatically. A translucent drinking glass, white lace on white, bicycle spokes, a model with flyaway hair, or a chair with open slats deserves more suspicion.
| Signal | Likely problem | Route |
|---|---|---|
| Subject touches the canvas edge | Possible clipping or an already-cropped source | Review |
| Very small foreground area | Wrong subject, distant product, or bad mask | Review |
| Large transparent region inside the subject | Glass, holes, handles, spokes, or lost detail | Review by category |
| Unexpected output dimensions | Crop or orientation rule changed the asset | Fail before publish |
| Variant mapping has more than one match | A red product may land on the blue variant | Block publish |
| Ordinary geometry and known category | Low-risk catalog image | Auto-approve |
Thresholds should be tuned by product category. A large transparent interior is suspicious for a sweater and completely normal for a bar stool.
Review the output on at least two backgrounds: a light neutral and a dark or checkerboard surface. White halos hide nicely on white listing pages and then reappear in a dark-mode ad six weeks later. If the pipeline creates a transparent master, review that master rather than only the flattened white derivative.
05
Publish with identity, ordering, and rollback intact
Catalog publishing fails in more ways than “the upload returned an error.” The new image may attach to the product but not its variant. It may land at the end of the media gallery instead of replacing position one. Alt text can disappear. A retry can append a duplicate. A delayed platform job can finish after your worker has declared defeat. Treat the platform response as the beginning of verification, not a ceremonial green light.
A safer replacement sequence
- Create or upload the new media while the current media remains live.
- Wait until the commerce platform reports the asset ready and returns a stable media ID.
- Attach it to the exact product and variant associations recorded on the job.
- Set alt text and the intended gallery position; verify both by reading the product back.
- Switch the new asset into the live position.
- Keep the previous media ID for a rollback window before deleting anything.
Variant identity is a hard gate
Do not guess a variant from image color, upload order, or whichever SKU happens to contain the same six characters. If the mapping is missing or ambiguous, stop. A failed job is recoverable; a blue shirt shown on the red-shirt option is a conversion-rate experiment nobody requested.
06
Model cost with retries and review, not just API calls
The API line item is easy to calculate. The operational cost is broader: downloads, storage, derivatives, duplicate prevention, manual review, and reprocessing when a source or recipe changes. Start with a sample of your own catalog and measure pass rate by category. A pipeline that auto-approves 92% of shoes and 40% of glassware should not use one blended planning assumption.
| Plan | Current structure | When it fits |
|---|---|---|
| Starter | $5 monthly or $50 annually; Studio-only | Manual cleanup in the browser, not an automated API pipeline |
| Business | $20 monthly or $200 annually, plus $0.01 per API image | Production integrations and ordinary catalog volumes |
| Business trial | 1,000 trial API calls only | A bounded pilot; not a recurring monthly call allowance |
| Enterprise | Volume pricing as low as $0.0025 per image | High-volume catalogs that need negotiated capacity and economics |
Plan against attempted billable work, then reduce duplicate calls with idempotency. Confirm current pricing before publishing financial projections.
Capacity planning should include bursts. A nightly supplier import may contain a month of images at once. Pace requests below the account limit, cap worker concurrency, respect retry guidance, and add jitter so every failed job does not wake up simultaneously. Backpressure is much cheaper than discovering that 40,000 messages can all be “urgent” at the same time.
07
Roll it out by category, with a real off switch
Begin in shadow mode. Process images and compare candidates to the current assets without publishing. Then choose one forgiving category, send every result to review, and record why reviewers reject it. When the rejection reasons stabilize, convert the obvious cases into automatic gates and let low-risk images publish.
Pipeline health
Queue age, processing latency, retry rate, duplicate suppression, permanent failures, storage failures, and publish verification failures.
Catalog quality
Auto-approval rate by category, reviewer rejection reasons, rollback rate, variant mismatches, clipped products, halo reports, and time from intake to publish.
Blast radius
Feature flags by supplier and category, maximum daily publishes, a pause switch, retained old media IDs, and a recipe version that can be rolled back.
After trust is earned, expand category by category. Keep random samples from the auto-approved stream in human review; otherwise supplier photography can change while the pass rate looks stable. Automation is not finished when nobody looks at it. It is finished when the system makes looking selective, measurable, and useful.
Build for the second run
A good catalog pipeline makes reprocessing predictable.
Preserve the source, version the recipe, keep product identity attached, and separate processing from publishing. Then a new canvas rule or improved model becomes a controlled catalog update instead of a second migration project.
Read the product photo cleanup guide