Recurring imports

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. For everything else there is no self-service connector builder: you won’t find a screen where you register an arbitrary upstream source, point it at a folder, and set a schedule. Those 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 four ways data arrives

​

Connect Shopify

The only upstream system with a built-in, self-serve connector. You install the MerchantOps app on your store, connect it to your organization, and import the catalog whenever you want it refreshed — options, metafields, and prices included. Re-importing updates what changed and never deletes anything on either side. See Shopify for the full round trip, including publishing approved changes back to the store.

​

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.

​

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 properties 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.

​

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 outside of Shopify it has no equivalent self-serve surface today: you cannot register an arbitrary upstream system in the app the way you register a publish target.