Automated product descriptions for .UZ stores via API
A five thousand SKU catalogue cannot be written by hand, and empty product cards neither index nor sell. API generation solves it, provided you build the controls.
Framing the problem
The typical picture in Uzbek e-commerce: cards carry a name and a price, while the description is either missing or copied from the supplier along with someone else's brand. Search engines treat such pages as thin and the buyer finds no answers.
The goal of generation is not prose but closing the buyer's questions and producing unique text for indexing. A good description answers three things: what it is, who it suits, and how it differs from the neighbouring SKU.
The precondition is source data. Generating from a name alone produces filler. You need attributes: material, dimensions, contents, country, warranty. If the attributes are missing, fix them first and generate afterwards.
The generation pipeline
The scheme is simple: export products without descriptions, send batches to the model API with a prompt and attributes, write results into a draft field, review manually or automatically, publish. The draft stage is mandatory; publishing straight through is not an option.
Batches of 20-50 products from one category work better than per-item calls: the model sees category context and stops repeating the same phrasing. It is also cheaper thanks to the shared system prompt.
For large catalogues use asynchronous processing with a queue and retries. Five thousand SKUs is hours of work, and the process must survive a server restart without losing progress.
Avoiding cookie-cutter text
The main danger is a thousand descriptions differing only by product name. Search engines recognize the template and devalue the whole section. The fix is structural variety: define several text schemes in the prompt and rotate them.
The second technique is feeding the prompt the real differences between this SKU and its neighbours in the category. When the model can see what sets an item apart, the text becomes specific on its own.
After generation, run an automatic similarity check across descriptions within a category. A rate above a sensible threshold means the prompt needs changing, not the results publishing.
Languages and Uzum Market
Generate in Russian and Uzbek at minimum. Do not translate a finished description — generate separately per language from the same attributes, or you get Russian syntax calqued into Uzbek that reads unnaturally.
If you also sell on Uzum Market, account for the marketplace's requirements on description length and structure: they differ from what is optimal on your own site. Keep two variants derived from one attribute set.
Full text duplication between your site and the marketplace is undesirable: in search the marketplace usually wins on domain authority and your page gets no traffic.
Cost and control
Reference point: generating a bilingual description for one SKU costs fractions of a cent, and a 5,000 SKU catalogue fits into roughly 300,000 – 1,200,000 UZS of one-off API spend depending on text length and model.
The main cost is not the API but attribute preparation and proofreading. Budget for human spot checks on at least 10 percent of items, with full review in categories carrying legal requirements — children's goods, electronics, cosmetics.
Never generate specifications. The model must not invent weight, composition or warranty period: those fields come from the database as-is, and only the connecting text around them is generated.