Skip to main content
This page is about getting data into MerchantOps repeatedly, rather than one file at a time. Read it if the source of truth for your catalog lives in another system and changes on a cadence.
There is no self-service connector builder in the app: you won’t find a screen where you register an upstream source, point it at a folder, and set a schedule. Recurring imports are either driven by your code against the API, or set up as a managed feed that MerchantOps builds and runs for you.

​
The three ways data arrives

Upload a file

A person uploads a CSV or an edited Excel export. Immediate, no setup.

Call the API

Your system pushes products on its own schedule. You own the scheduling.

A managed feed

MerchantOps builds and operates an ingestion path for your upstream system.

​
Upload a file

The self-serve path, covered in uploading products and, for source documents, the Lakehouse. Best for a one-off batch, a correction pass, or data you’re preparing by hand.

​
Call the API from your own system

The product import endpoints are part of the public API — the same ones the dashboard uses when you upload a file. If you can run a scheduled job on your side, you can drive imports from it: export from your system, post the products, read the per-row result. You own the schedule, the retries, and the alerting; MerchantOps owns everything downstream of the request. This is the honest answer for most “we want a nightly sync” cases where you have engineering capacity.

​
A managed feed

For upstream systems that can’t call an API — an ERP that only knows how to drop a file, for example — MerchantOps can build and operate the ingestion path for you: picking the file up on the agreed cadence (commonly a file drop over SFTP), mapping its columns onto your product types and properties, and importing it. This is bespoke work arranged with MerchantOps, not a feature you switch on. Each feed is built against a specific file format, cadence, and set of business rules, and it is operated by MerchantOps rather than configured by you. Talk to your MerchantOps contact if you need one.
Because a managed feed is built for one specific upstream system, nothing on this page should be read as a description of a generic product surface. What your feed does — which columns it reads, which fields it is allowed to overwrite, how often it runs — is defined in the agreement for that feed, not by a setting in the app.

​
What a recurring import produces

Whichever path brings the rows in, the result is ordinary MerchantOps data:
  • Rows become products, with their columns mapped onto the attributes their product type defines.
  • A row that matches an existing product adds a new version rather than overwriting history.
  • If enrichment is requested, new products are queued for enrichment and tracked as a Job.

​
How runs are reported

Import runs report rows as created or failed, with a per-row error list (row number, product key, and reason). Paths that support merge mode also report skipped rows — ones that matched an existing product and changed nothing.
There is no “updated” count on any import path. A row that changes an existing product is reported under created, because the import wrote a new version of it. Don’t read created as “new products”; read it as “rows accepted”.

​
Not to be confused with publishing connectors

A publishing connector sends approved data out of MerchantOps to a storefront or downstream system, and that is a generic, documented pattern you can build against — see build your own connector and the VTEX reference connector. Import is the opposite direction, and it does not have an equivalent self-serve surface today.

Uploading products

The self-serve path: CSV and Excel uploads, merge mode, per-row results.

Jobs

Watch enrichment triggered by an import and review per-row errors.

The Lakehouse

Bringing in source documents rather than catalog rows.

Agents & tools

The API surface your own scheduled job would call.