Skip to main content
The enrichment pipeline is a four-stage loop. You run it on whatever cadence makes sense — a nightly batch, a continuous stream, or an on-demand run for a handful of SKUs.

Authenticate

Every request carries your X-Api-Client-Key header. Your key is bound to a single merchant organization and a set of scopes. No key, no access.

Read the schema

Fetch the merchant’s attribute templates. These describe the attributes the merchant cares about — names, units, data types, and priority — so your model enriches against a known schema instead of inventing fields.

Read the catalog

Pull products to enrich — either a paginated export of the whole catalog or a targeted SKU lookup. Each product carries identity, the current enrichable fields, and read-only context (brand, categories, images).

Generate & submit proposals

Run your model, then submit the enriched fields. Each item carries a confidence score so reviewers can sort the easy wins first. Every accepted item becomes a pending revision — never a live change.

The data flow

What “enrichment” means here

Each product exposes a small set of enrichable fields that your proposals may change, plus read-only context you should use as input but cannot modify.
Any non-enrichable or empty field in a submission item is silently ignored and reported back in the ignoredFields array of the result. See Submitting proposals.

Guardrails

The API enforces a few hard limits so a runaway job can’t overwhelm the catalog: Stay within these and design your batching around them — see each endpoint’s reference page for the exact error responses when you exceed them.