Why Start From the Photos #
The usual AI listing workflow is: type a product name, paste some keywords, get a title and five bullets. The output reads fine and is frequently wrong, because the model is working from a name and inferring the rest.
Your product photographs already contain most of what a good listing needs — material, finish, colour, shape, what it holds, what it sits next to for scale, whether it looks handmade or machined.
In one line
Send the images to a vision model along with your keywords. The copy stops guessing at attributes and starts describing the thing in the picture — and you get SEO image filenames and tags out of the same call.
The Pipeline #
- Upload the photographs
Store them against the product, not just in the request. You will regenerate copy more than once, and you want the same inputs each time.
- Assemble the context
Images, plus a weighted sample of keywords from your keyword bank, plus the product type. Sampling rather than pasting everything keeps successive generations from being identical.
- Call the model with an SOP prompt
The rules for this category — structure, tone, banned words, length limits — live in editable data, not in code. See below, this is the part that decides quality.
- Get back more than a title
Title, bullets, description, tags, and SEO-friendly image filenames. Ask for the filenames explicitly — they are free at this point and nobody writes them by hand.
- Run a compliance gate before anything is stored
Length limits, banned words, filename format. Block on failure rather than warning.
Keeping the whole generated set versioned and diffable is worth the small extra effort. Copy gets regenerated, compared and rolled back constantly, and "which version is live" becomes a real question by the tenth product.
The SOP Belongs in the Database, Not the Prompt String #
This is the design decision that matters most, and it is easy to get wrong on day one.
Every category has rules — what a title must lead with, how bullets are structured, words that must never appear, tone. The temptation is to bake them into the prompt in code. Don't.
Make the template a database record, scoped to a product type, editable in your own UI. Three reasons:
- The person who knows the rules is not the developer. They should be able to tune wording without a deploy.
- Categories genuinely differ. A template resolved by product type lets one system serve very different catalogues.
- Tone can be a requirement, not a preference. Some categories demand real care — anything bought under emotional circumstances, anything medical-adjacent, anything for children. A grief-appropriate template is not a nice-to-have in those categories, and it needs to be tunable by someone who understands the buyer.
Ship a seed banned-word list, then replace it. Whatever list you start with is a guess. The real one comes from the client's own compliance history and Amazon's category rules — treat your default as scaffolding and plan to swap it.
Keywords: Sample, Don't Dump #
If you have a keyword bank, the naive move is to paste all of it into the prompt. That produces keyword-stuffed copy and, worse, identical copy across products in the same theme.
A weighted random sample per generation works better: high-value terms appear most of the time, the long tail rotates. Two products in the same category get genuinely different copy, and regenerating gives you a real alternative rather than a paraphrase.
Where the weights come from matters — terms the product actually ranks for should outweigh incidental ones. If your keyword source has no relevance signal, you may have to derive one.
Watch case sensitivity on your theme keys. If keywords arrive from more than one source — a CSV import and an API pull, say — "Cutting Board" and "cutting board" become two separate banks, and your sampler quietly sees half the keywords it should. Canonicalise at the application layer.
What Still Needs a Human #
Being clear about this is what makes the tool trustworthy to the people who have to use it:
- Facts the photo cannot show. Dimensions, weight, capacity, certifications. A vision model will describe what it sees and should not be inventing measurements — ask the operator for those and pass them in as context.
- Category compliance. The gate catches length and banned words. It does not know your category's specific claim restrictions.
- The final read. Especially for sensitive categories. Someone signs off before it publishes.
- Video. Worth stating plainly: text-and-vision models generate text, not video. If you want listing video, that is a separate tool or a slideshow assembled from your existing images — not something the copy model produces.
The honest framing for the whole thing: this removes the blank page and the tedium, not the judgement. A good operator with this pipeline gets through ten times the listings. An absent one ships ten times the mistakes.
Publishing what you generate? Writing to the catalogue needs the Product Listing role, which triggers an app re-review and a per-account re-auth — see the role process and bundle your requests.
FAQ #
Can Claude write Amazon listings from product images?
Yes. Sending product photographs as image blocks alongside your keywords lets the model describe the actual product — material, finish, colour, scale — rather than inferring attributes from a product name. The same call can also return tags and SEO image filenames.
Where should listing rules and tone live?
In an editable database record scoped to product type, not hard-coded in the prompt. The person who knows the category rules is usually not the developer, and categories differ enough that one fixed prompt does not serve them.
Should I put all my keywords in the prompt?
No. Dumping the full bank produces stuffed and repetitive copy. Take a weighted random sample per generation so high-value terms recur and the long tail rotates, giving genuinely different copy per product.
Can an AI model generate listing video?
Not a text-and-vision model — those produce text. Listing video requires either a dedicated video model or assembling a slideshow from your existing product images.
What has to be checked before publishing generated copy?
Length limits and banned words automatically, blocking on failure. Then a human for anything the photo cannot establish — dimensions, weight, certifications — and for category-specific claim rules, which an automated gate will not know.
Related guides
Amazon SP-API
The SP-API Reports Pattern Everyone Gets Wrong (Async, Step by Step)
The SP-API Reports API is asynchronous — request, poll, download, decompress — and most broken integrations either treat it like a synchronous call or poll it straight into a throttle. Here's the correct four-step flow, the status states that trip people up, and the gzip gotcha at the end.
Read guide →Amazon SP-API
Amazon Vendor Central API: What 1P Vendors Can Actually Automate
Vendor Central (1P) has a real API surface through the SP-API vendor family — retail analytics, purchase orders, shipments, invoices, and direct fulfillment. Here's what's genuinely automatable, what still isn't, and where the fastest wins are for a 1P vendor.
Read guide →Amazon SP-API
Amazon SP-API 403 Unauthorized: Every Cause and How to Fix It
A 403 "Access to requested resource is denied" from the SP-API almost never means your credentials are wrong — it usually means a role, a token, a region, or an authorization is mismatched. Here are the eight causes that produce a 403, in the order worth checking them, with the exact fix for each.
Read guide →Don't want to build this yourself?
I set this up for sellers and agencies every week. Book a free 30-minute audit of your Amazon data & PPC setup — you'll leave with a plan either way, whether we work together or not.