Catalog model
A product has a stable
key within your organization and carries a name,
product type, brand, and a list of attributes (its source records where the
data came from). Products are versioned — the latest (or production)
version holds the richest data, and enrichment adds new versions rather than
overwriting. See Versioning.A specific purchasable variation of a product — e.g. a size/color/width
combination. Variant keys accept merchant formats (dots, spaces, slashes).
A template that links a product to the property definitions it should carry.
Product types must exist before products that reference them.
Defines a single attribute: its type (enum/text/number/boolean), whether it’s
required, facetable, or searchable, and whether it lives at the product or
variant level. Property definitions must exist before the product types that
reference them.
Brand identity is shared reference data across the platform.
Data flow
A shared store of product, technology, and document data used to enrich your
catalog. Enrichment searches it before scraping the open web.
Imports, enrichment, and exports run as jobs with
total, processed, and
failed counters plus a computed progress percentage. Track them on the
Jobs page or via the API.For each product, the pipeline searches the lakehouse, finds and scrapes the
brand site, generates missing content with an LLM, and standardizes attributes.
Sources merge by priority: brand site > lakehouse > merchant input >
AI-generated.
Pricing & publishing
Prices are managed as records and grouped into batches for review and
scheduled publishing. MAP (Minimum Advertised Price) policies are tracked
separately as legal/compliance data.
A destination (e.g. a VTEX store and environment) a batch is published to.
Publishing is batched, idempotent, versioned, and audited per target.