This article covers a real case of ours, in production: a multichannel retailer with a physical shop, a branch and online sales, with more than 20,000 products in its management system and about 13,000 active listings across Tienda Nube (the leading Latin American store platform) and Mercado Libre (the dominant marketplace in the region). Before the project, four people spent their entire day listing products by hand. The source system is a custom desktop application with no API. What follows is the full architecture of the pipeline we built, the real numbers, and the design decisions: what we automated, what we left in the hands of the team, and why.
In this article:
The problem: manual product listing does not scale
Manually listing a product on a multichannel ecommerce is not one task, it is a chain of tasks. In this case, for every product that came in, someone on the team had to:
- Search whether it was already published, in the store or on the marketplace, possibly under another name or in another size or color.
- Write the title and description, in the brand voice and with the correct technical data.
- Load the product into the store, with photos, category, variants and price.
- Replicate it on the marketplace, which has its own category structure, required attributes and publishing rules.
- Apply the pricing rule, which is not the same number on both channels.
Each step is short. The whole chain, multiplied by dozens of new products per week, kept four people busy full time. And the first step is the treacherous one: when the manual search fails, a duplicate gets published, and duplicates on a marketplace degrade the ranking of the original listing.
The usual instinct is "let’s hire one more person" or "let’s use ChatGPT for the descriptions". Neither attacks the real problem: the entire circuit depends on a person looking at two systems that do not talk to each other and deciding, product by product, what to do.
Why a connector is not enough
Connectors that sync a store with a marketplace exist, and they do their job well: if your catalog is already clean on one channel, they replicate it on the other and keep prices and stock aligned. If that is your only problem, a connector is the right solution and you do not need custom development.
The problem in this case started before the first channel. Three reasons a connector could not solve it:
- The source is not the store, it is the management system. The master catalog lives in a custom desktop application, with no API and no external access to its database. No commercial connector plugs in there.
- Nobody decides what is new. The management system holds more than 20,000 products; the store, 13,000 listings. A connector replicates what is already published, but cannot answer the central question of listing: out of everything that came in this week, what is a new product, what is a variant of something already published, and what is already online under a different code?
- The copy does not write itself. A connector copies existing titles and descriptions. At listing time they do not exist yet: there is an internal code, a two-word description and a price.
The design conclusion: the project was not "connecting two platforms" but building a pipeline with its own judgment between the management system and the sales channels.
The architecture, stage by stage
The complete pipeline has six stages. The stack: n8n as orchestrator, Postgres (Supabase) as our own data layer, the Claude API for the copy, and the official APIs of Tienda Nube and Mercado Libre for publishing. No piece is exotic; the value is in how they split the work.
1. Ingestion: a daily export, without touching the source system
Since the management system has no API, the integration took the simplest path that works: the system vendor scheduled an automatic export of the full catalog (code, description, barcode, price, category, date of first purchase) that lands every day at 5 AM in a Google Drive folder. An n8n workflow detects the file half a minute later, validates that the format is what it expects, and ingests it. If the file does not arrive or comes incomplete, it fires an alert instead of processing broken data.
Nobody on the team sends anything or announces the file arrived. That is the bar for a well-solved ingestion: it disappears from everyone’s routine.
2. Staging: our own data layer between the system and the channels
The pipeline does not write straight from the export to the store. In between there is our own Postgres database holding the vocabulary of the project: which product in the system maps to which listing on each channel, what state each one is in (new, variant, published, pending, error) and what happened on every publishing attempt.
This is the layer most integration projects skip, and the reason they later cannot answer basic questions like "was this product already published?" or "why did this one get stuck halfway?".
3. Detection: new, variant or already published
Every product in the export is classified with business rules, not magic:
- The date of first purchase in the system separates new from historical: a product first bought this week is a listing candidate; one from 2023 already had its chance.
- The map of what is already published (read through the APIs of both channels) prevents duplicates: if the barcode or SKU is already online, it is not a new listing.
- The variant rules distinguish a new product from a new size or color of something already published, which does not get its own listing: it is added to the existing one.
Whatever cannot be classified with confidence does not get published: it goes to a queue of doubtful cases reviewed by a person. This case left a data point that shows how much tuning rules pays off before adding more AI: a single business rule (treating whatever already appears in the store as published) brought the doubtful cases down from 4,697 to 1,199, and loading brands and characters per category resolved more than 3,000 additional products without reviewing them one by one.
4. Copy with AI: the model writes, hard data is injected
Titles, descriptions and keywords are generated by Claude from the product data and examples of the house style. The important design decision is what does not go through the model: the internal code, the barcode, the price and the measurements never enter the prompt as text to write. They are injected from staging when the listing is assembled.
The reason is the typical failure mode of using a chatbot for product sheets: the model "adjusts" a number. An invented price or an altered code on a live listing is exactly the kind of error that makes a company abandon automation. Separating writing (the model) from data (the database) eliminates that class of error by construction, not by good intentions.
5. Human review: in the tool the team already uses
Nothing gets published without a person approving it. Ready products appear as cards on the Notion board the team already used to organize their work, with the generated copy, the photos and the data. The team reviews, corrects whatever is needed and approves from there; the pipeline reads the approval and only then publishes.
Two details of this stage are worth more than the stage itself:
- Zero new tools. The review happens where the team already worked. The learning curve of a new interface kills more automations than bugs do.
- Corrections are recorded. Every time the team corrects a generated text, that correction is stored and feeds the prompt tuning. Human review is not just a control: it is the improvement mechanism of the system.
6. Publishing: the store first, the marketplace after
Once approved, the pipeline publishes the product to Tienda Nube through its API and replicates it on Mercado Libre applying the pricing rule of each channel. On Mercado Libre it first attempts a match against the official catalog by barcode, which in this case works for roughly 90% of products; the rest falls back to a traditional listing, with review. All of it with API rate limiting: listings go out in batches, not in an avalanche.
What to automate and what to keep human
The question that defines a project like this is not "what can AI do?" but "what does the system know, and what does only the team know?". This is how it split in this case:
| Decision | Who makes it | Why |
|---|---|---|
| Detecting a new catalog arrived | System | A data event, no judgment required |
| Classifying new / variant / already published | System (rules) | Explicit business rules over data the system has |
| Writing title, description and keywords | AI | It is language; hard data is injected separately |
| Whether there is real stock to publish | Team | The stock figure in the system does not always match physical reality |
| Whether a product is for the shop or the web | Team | It is in no field; it is a commercial decision |
| Kits and bundles | Team | Their composition requires case-by-case judgment |
| Final approval before publishing | Team | The guarantee that nothing wrong reaches a public channel |
The most important row is the last one. In AI automation demos, the system publishes on its own and everyone applauds. In production, human approval before publishing is what lets the system run every day without anyone fearing it. It is not a limitation of the project: it is the reason the client uses it.
The numbers of the case
- 20,000+ products in the source management system, ~13,000 active listings across the two channels.
- 4 full-time people dedicated to manual listing before the project.
- From 4,697 to 1,199 doubtful cases after applying a single business rule (treating whatever already appears in the store as published).
- 3,000+ products resolved automatically by loading brands and characters per category, with no individual review.
- 1 in 5 products has no barcode; the pipeline resolves them by searching by SKU instead of discarding them.
- ~90% match rate against the official Mercado Libre catalog by barcode, with a fallback to traditional listings for the rest.
- 100% automatic ingestion: the full catalog comes in every day at 5 AM and is processed on its own, with nobody sending or announcing anything.
How to approach a project like this
If your operation looks like this case (a management system of your own, multichannel sales, and people loading products by hand), this is what is worth verifying before starting:
- A way to get data out of the source system. You do not need an API: a scheduled automatic export to a shared folder is enough, and it is usually something the system vendor can configure in days. What does not work is depending on a person generating the export by hand.
- API access to your sales channels. Tienda Nube, Mercado Libre, Shopify and WooCommerce all have documented official APIs. The credentials must belong to your company, not to the provider building the development.
- A person who reviews. The bottleneck stops being loading and becomes approving. It is a much smaller role (reviewing pre-assembled cards instead of creating listings from scratch), but it has to exist.
- Your business rules, written down. What makes a product "new", how sizes and colors relate to the parent product, what the pricing rule per channel is. If those rules only live in the team’s heads, the first phase of the project is writing them down.
On timelines: a pipeline like this is a project of weeks, not days. In this case it was planned in 6 to 8 weeks, with two verifiable intermediate milestones: the connection and work queue running, and the first batch of products published end to end with team review. Distrust timelines measured in days: they almost always mean nobody looked at the edge cases of your data (the products without barcodes, the bundles, the variants).
About how we work on this
At Duotach we build this kind of pipeline for companies in Argentina and Latin America, including the case in this article, with AI where it adds value (copy, classification) and explicit rules where the business has them. If you have a team loading products by hand and a system that does not talk to your sales channels, see AI automation for companies or contact us.
Frequently asked questions
Can product listing be automated if my management system has no API?
Yes, and it is the most common scenario in mid-sized companies. The practical alternative is a scheduled automatic export (a file with the full catalog that the system drops daily into a shared folder) which the pipeline detects and processes on its own. In the case covered here, the source system is a custom desktop application with no API, and ingestion runs every day with no human involved.
Does the AI publish products on its own?
Not in our design. The AI writes titles, descriptions and keywords, and the system classifies and prepares each listing, but a person on the team approves every product before it goes out to a public channel. That review is a design decision, not a technical limitation: it guarantees no error ever gets published, and the corrections it produces are what the system learns from.
What about prices and codes? Can the AI make them up?
That risk exists when you ask a chatbot to write the whole product sheet. That is why hard data (internal code, barcode, price, measurements) never goes through the AI model: it is injected directly from the database when the listing is assembled. The model only writes language; the numbers come from the system. A wrong price is eliminated by construction.
Does it work with a store and a marketplace at the same time?
Yes. The pipeline publishes to the online store first and replicates to the marketplace through their official APIs, applying the pricing rule of each channel. On Mercado Libre it first attempts a match against the official catalog by barcode (around 90% of products in our case) and falls back to a traditional listing for the rest.
How long does a project like this take?
A complete product-listing pipeline is a 6 to 8 week project for an operation with tens of thousands of products, with verifiable intermediate milestones (the connection working, the first batch published end to end). The day-long timelines some tools promise apply to replicating an already-clean catalog between channels, which is a different and much smaller problem.
Does this replace the team that loads products?
It changes their job more than it eliminates it. The repetitive work (transcribing, writing from scratch, replicating on each channel) disappears; what remains is the review and the decisions the system cannot make: whether there is real stock, whether a product goes to the store or stays in the physical shop, how a bundle is put together. In this case, four people dedicated to manual listing get most of their time back for other tasks.
What about products without a barcode?
They are more common than you would think: in this case, one in five. Without a barcode, the automatic match against what is already published fails, and the product would show up as new even if it has been online for years. The solution was to also search the channels by SKU. It is the kind of edge case a serious project surveys at the start, because ignoring it creates duplicates.
How we approach connecting a management system with AI in other processes is covered in integrating AI with your ERP and automating invoices with AI.