
Anatoliy Dankov
CTO

Quick answer:
Product data enrichment runs from about $0.30 to $0.75 per record on published self-service pricing, and large catalogs are quoted per project. The spread comes from what you send in rather than how many products you send. A record arriving with a full supplier description sits at the bottom of that range. A record with an item number, a price, and one photo sits at the top, because everything else has to be derived, checked, and placed in your taxonomy.
Vendors quote a single per-SKU figure because it is easy to compare. It also hides the part that determines your invoice: enrichment is not a single operation but six, and your catalog does not consist of a single kind of product record.
This breakdown covers what each of those six operations contributes to the price, what makes one SKU cost several times another, how enrichment vendors structure their billing, and how to estimate a figure for your own catalog before you ask anyone for a quote.
Published per-record rates come from the Shopify App Store and from vendors serving the same segment, where pricing is public and a merchant can start without talking to anyone. Enrichment for large catalogs is quoted per project and sits outside that range.
The self-service layer is worth reading closely, because it exposes a split that vendors serving larger catalogs keep behind a quote. Some tools generate a description from whatever fields already exist, and others derive the missing fields first.
Type of tool | How it charges | Published example | What happens to a sparse SKU |
|---|---|---|---|
Built into the platform | Included in the plan | Shopify Magic, no extra cost | Generates from whatever fields exist |
Description generators | Flat rate per product or credit | Orbo: $14 for 40 credits, one credit per description | Same price, weaker output |
Bulk generation apps | Monthly credit allowance | Avada 5,000 credits/month; ChatGPT-AI Product Description 120,000 credits/month | Same allowance consumed, weaker output |
Enrichment platforms | Separate charges per operation | Describely: $0.75 per product, $0.55 per enrichment credit, $0.05 per image credit | Costs more, because missing data is derived first |
Vendor-published pricing, accessed 9 September 2026. These rates apply to self-service tools sold to individual merchants. They do not cover enrichment for large catalogs, which is quoted per project.
The fourth row changes how you read the other three. A flat per-product rate looks cheaper because it prices a single operation. Enrichment platforms bill several, and the gap in the invoice reflects a real difference in what each does with an item number and a photograph.
On a sparse record, a flat-rate generator does not charge you more. It produces a description built on assumptions, and the cost surfaces later as returns, support tickets, and marketplace listings rejected for missing required attributes.
Rates rise once a catalog stops fitting a self-service tool. Enrichment at scale involves supplier file parsing, mapping to an existing taxonomy, validation rules, and integration with the system that holds the catalog, none of which a per-product credit covers. Vendors serving that segment quote per project, which is why published figures for it are almost impossible to find.
Profile your catalog first. The number that decides your bill is not how many products you hold, but what share of them arrive with structured attributes already in place, and what share arrives as an item number, a price, and one image.
A retailer importing from forty suppliers usually has both extremes inside the same file. The blended cost lands wherever the sparse range is heavy, and no vendor can quote against that split until you have measured it.
Turnover, in almost every case.
Enrichment is charged per operation, and an operation happens when a record is created or changed. A distributor with 200,000 stable industrial products enriches once and then touches a small share each month. A fashion retailer with 20,000 SKUs and four collections a year re-enriches most of the catalog annually.
The second business holds a tenth of the catalog and pays the larger bill. Budget against how often your assortment changes rather than against how many products you have.
Enrichment is not one operation. A vendor quoting a single per-SKU rate is averaging six distinct pieces of work, and knowing which ones your catalog actually needs is what turns a quote into a budget.
Product data arrives as spreadsheets, CSV exports, PDF catalogs, and occasionally as images of printed spec sheets. Each format has to be read and turned into structured records before anything else can happen.
Spreadsheets from a single supplier are cheap to handle once the layout is known. Forty suppliers with forty layouts is a different task, and the work is recurring rather than one-time, because suppliers change their exports without telling anyone.
Supplier fields rarely match your own. One sends colour, another sends Color / Finish, a third puts the colour inside the product name. Mapping resolves those into the attribute your catalog uses, and normalises the values behind them: 40 cm, 400 mm, and 0.4 m all becoming one unit.
This is the operation most often underestimated, because it looks like a one-time setup and behaves like an ongoing one.
The step most tools sell as the whole product. Text is written from the structured attributes, in your tone, at the length each channel accepts.
Output quality here is set almost entirely by the two operations above it. A description generated from six attributes reads like a description generated from six attributes, whatever model produced it.
Our guide to product data enrichment services covers what that upstream work involves in more detail.
Every product has to sit somewhere in your category tree, and often in a different tree for each marketplace. Amazon, Google Shopping, and a national marketplace each define their own required fields per category, and placing a product wrongly means the listing is rejected or buried.
Cost here scales with the number of channels rather than with the number of products.
Background removal, resizing to channel specifications, renaming to match SKU conventions, and linking assets to the right record. Vendors that price this separately usually charge the least for it per unit, and the volume makes it add up regardless.
The operation that determines how much manual work lands on your team afterwards. Without it, every generated value has the same status: someone has to check all of them, or nobody checks any of them.
With a recorded source for each filled field and a confidence score alongside it, review becomes targeted. Your team looks at the values the system was unsure about, and accepts the rest.
Most self-service tools skip this step entirely, which is part of why their per-product rate is low. The work does not disappear; it moves to your merchandisers.
Four billing models cover the market. The model matters more than the rate, because each prices a different thing, and only some of them scale the way a growing catalog does.
Model | What you are billed for | Predictable? | Published example |
|---|---|---|---|
Per SKU | One generation run per product | Yes, until you re-run | Describely: $0.75 per product |
Per credit | A monthly quota of operations | Only if usage is steady | Plytix: 500 AI credits included per plan, more purchased in packs |
Per operation | Each step performed on each record | Varies with input quality | Describely: enrichment and image credits billed separately |
Bundled into a licence | Included up to a limit, metered above it | Yes within the limit | Salsify does not publish how its AI features are billed |
Vendor-published information, accessed 9 September 2026.
The simplest model and the easiest to compare. One rate, one product, one run.
It prices a first pass and nothing else. Re-running a product because a supplier updated a spec, or because a new channel needs different fields, consumes the rate again, so a seasonal catalog pays a multiple of the rate rather than the rate itself.
Credits are the least comparable unit in the category, because no two vendors define one the same way.
Orbo counts one credit per description. Describely separates the concept, so a single record can consume several credits of different types. Plytix includes 500 AI credits with every plan and sells additional monthly credits on top, with usage depending on which AI features you run and how large the catalog is.
Three questions make credit-based quotes comparable:
Enrichment included in a platform licence behaves differently from a standalone tool. The operation runs against records the system already holds, with your taxonomy and validation rules in place, so parsing and mapping are not repeated on every run.
Pricing transparency drops sharply in this group. Plytix names its unit publicly. Salsify, which sells AI capabilities through its Intelligence Suite, publishes no information on how those features are billed, so the cost of enrichment cannot be separated from the platform quote at all.
That gap matters when you are comparing a $0.75 per-product rate against a platform proposal. One of those numbers is a price, and the other is a total that happens to contain one.
Three inputs produce a usable estimate, and none of them requires a vendor conversation.
Enrichment budget =
(records needing full derivation × full rate
+ (records needing partial derivation × partial rate
+ (records needing mapping only × base rate)
+ (annual re-runs × blended rate)
Export your catalog and count how many records carry structured attributes already, how many have a description and images but no structured fields, and how many are an item number, a price, and one image. One afternoon of work, and it determines most of the estimate.
What share of records were created or materially updated in the last twelve months. This drives the re-run line, which almost every first-time budget leaves at zero.
Each marketplace defines mandatory attributes per category. A channel added later re-runs part of the catalog rather than none of it.
Assumptions, all visible: 60% of records arrive with structured attributes, 30% have text and images but no structured fields, 10% arrive as an item number and one image. A quarter of the catalog changes each year. Rates are Describely's published pay-as-you-go pricing, used here because it is one of the few vendors that publishes a per-operation breakdown at all.
| Segment | Records | Operations per record | Rate | Cost |
|---|---|---|---|---|
| Structured attributes present | 30,000 | Generation only | $0.75 | $22,500 |
| Text and images, no attributes | 15,000 | Generation + 1 enrichment credit | $1.30 | $19,500 |
| Item number and image only | 5,000 | Generation + 2 enrichment credits + image | $1.90 | $9,500 |
| First pass | 50,000 | $51,500 | ||
| Annual re-runs | 12,500 | Blended | $1.03 | $12,875 |
Illustrative calculation using one vendor's published list rates, not a market average or a quote.
Two things this model shows that a per-SKU rate does not.
The blended cost is $1.03 per record, not $0.75, and the gap comes entirely from the 10% of the catalog that arrives with almost nothing. A retailer who improves supplier data intake changes this figure more than one who negotiates the rate.
The recurring line is a quarter of the first pass and repeats every year. Budgets built on the first-pass number alone run out in month fourteen.
At 50,000 records, volume moves the conversation off the published price list entirely. Pricing at that scale is quoted per project, and the quote reflects your completeness split, your channels, and whether the work runs against a system that already holds your taxonomy.
Use the model above to know what you should be quoted, then compare it against what you are quoted. The difference between those two numbers is the conversation worth having.
What would enrichment cost for your catalog?
Send us your completeness split and channel count, and we will come back with a cost range for your setup.
HootCore AI Product Data Enrichment is charged by credit, where one credit covers one enriched SKU. The rate is set by catalog volume, and the credits sit on top of the platform licence rather than inside it.
That structure separates two things that behave differently: the licence tracks catalog size, and enrichment tracks usage, so a stable catalog does not subsidise a volatile one.
Two choices affect what the work costs on your side rather than on the invoice.
Parsing and mapping happen once during setup rather than on every pass, because the taxonomy and validation rules are already there.
Review becomes targeted rather than exhaustive: your team looks at the values the system was unsure about and accepts the rest.
Enrichment currently runs through an API, so the starting point is a conversation about your catalog rather than a signup form.
From about $0.30 to $0.75 per record on published self-service pricing. Large catalogs are quoted per project.
On volume, yes. The cost that decides it is not the rate but the review time afterwards.
Some are identified and completed automatically, some are not. Expect part of that group to need manual work whatever tool you use.

Talk to our team and see how HootCore fits into your existing stack, from product data management to order fulfillment.