Supplier catalogue parsing
Listings are taken from each supplier in whatever way that supplier gives them up, and merged into one catalogue. Shared properties and units, images in your own storage, stock on a schedule of its own.
- Buildfrom $1,400
- Timeline1–3 weeks
- Supportfrom $420/mo
Who this suits: Shops and distributors whose suppliers hand data over in different ways, a file here, a portal there, only a web page in the third case, and merging it happens by hand.
What is in the first version
- supplier connections
- property map
- stock and cost
- duplicate merging
The figures above are the package this sits on: Parsing and reverse engineering. Anything past its edges the calculator adds before the work starts, not after.
How the path goes
- 01
Every supplier hands it over differently
A file is taken where there is one; a page only when nothing better exists, because pages break most often.
- 02
Differences map onto your reference
Colour and units arrive differently everywhere, and the correspondences live in a table a person edits rather than inside code.
- 03
An update never overwrites your card
The supplier refreshes price, stock and specifications; name, description and selling price stay yours, because every field has one owner.
What decides whether this works or annoys people
The export overwrites your edits
Ownership is assigned field by field before the first load, and a load touching a field it does not own stops.
A duplicate beats a wrong merge
A wrong merge ships the wrong item, so only a barcode or manufacturer number merges automatically, the rest goes to a person.
Stale stock costs more than price
A day-old price costs margin, a day-old stock costs an order, so stock runs more often and silence never means in stock.
What to measure once it is live
- items arriving with no hand editing
- cards with full properties and images
- duplicates merged automatically
- time from a stock change to the shop
Why this comes out faster
The shape of this one is known: the states, the edge cases and the things that usually go wrong have been decided before. Nothing here is a template, and the saving is not in your half of the work. It goes into your process, your content and the systems this has to talk to, which is the part nobody can have solved in advance.
A likely stack for this
Picked against the task when we scope it, not decided in advance. This is the shelf it usually comes off.
- Collection and formatsPythonFastAPIPlaywrightDocker
- Catalogue, images and matchingPostgreSQLRedisS3OpenAIAnthropic
- Schedule and watchingn8nTemporalTelegram Bot APIGrafana
Price it yourself, right here
Five steps, and you can see the number without leaving a contact. The estimate accounts for the kind of work, what you already have and what it will need inside.
These bills do not come from us
- hosting and image storage
- paid access to supplier portals
- AI model calls for matching properties
- a higher tier on your catalogue system
Asked before the first call
- Our supplier sends a spreadsheet that is different every time. Is that fixable?
- Up to a point: columns are read by content, not position, and a file that will not parse goes to a person. If the format shifts further, we say a fixed supplier export is cheaper.
- Can we use the supplier images?
- Technically they are easy to take, and we put them into your own storage. The right to use them comes from the supplier, agreed before we start: we do not take on somebody else’s rights.
- Where does it load into: 1C, a shop, a marketplace?
- Into the format of one of your systems, in the first version, named before the build because it decides which fields are mandatory. A second system is a separate line.