Maropost (Neto) and PIM: when you need one and how they connect

Maropost Commerce Cloud, formerly Neto, can hold product data well for a simple range. Once you sell thousands of SKUs from many suppliers, with variants, detailed attributes and several channels, that changes. A PIM becomes the governed source, and Maropost becomes one of the channels it feeds. Most Australian retailers and distributors we speak to sit somewhere between the two, so the useful question is which way your catalogue is heading.

What does Maropost do well for product data?

Neto, an Australian platform, has served retailers and wholesalers since 2009. Maropost announced its acquisition of Neto in March 2021, and the platform now sits under the Maropost Commerce Cloud name. It is a commerce platform with product management built in, not a bolt-on.

That product management is genuinely useful. Maropost’s knowledge base describes a product as “product details, images, dimensions, prices, specifications and more”. Item specifics give you structured name and value pairs such as size, colour and manufacturer, which drive filters and variant selectors. Variations use a parent and child model, and each child carries its own SKU, stock and price.

Maropost also handles its own channels well. Its marketplace tools run eBay stores, Amazon and your webstore from one control panel. The product API also supports customer price groups, so trade pricing can live in the same record.

For a contained range, that is enough. A few thousand SKUs, a handful of suppliers and a webstore plus eBay do not need a separate system. We would not tell that business to buy a PIM. If you are unsure where a commerce platform stops and a PIM starts, our guide to PDM, PIM and MDM draws the lines.

Where does Maropost reach its limits?

The limits are not faults. They come from Maropost being built to sell products, not to govern product data arriving from hundreds of sources.

Attribute model: specifics that differ by category

Maropost stores a specific as a name and a value. Its AddItem documentation allows 50 characters for the name and 150 for the value. That works well for filters and variants.

The strain shows when categories need different attributes. A cable needs conductor size and length. A pump needs flow rate and head. Take a rule such as “every circuit breaker needs rated current in amps before it goes live”. That is exactly what a PIM’s attribute families, data types and completeness checks are built for. In our experience, Maropost teams keep those rules in spreadsheets and in people’s heads.

Variants: parent and child structures with many options

Maropost’s guide to adding variation products is clear. The parent is not purchasable and stores default information. Every child needs a value for each specific, and every combination must be unique. That is good discipline.

The problem is volume. A work shirt in six sizes and eight colours is 48 children. Add fit and length and it runs into the hundreds. Supplier data usually arrives at child level, while your copy is written at parent level. Keeping the two consistent across hundreds of families is where manual effort piles up. When a supplier changes one colour name, someone has to find and update every child that uses it.

Supplier imports: CSV loads and manual fixes

The Product Import Wizard accepts CSV (preferred) or XML, in a simple or custom format. SKU is the unique identifier that ties rows to products. That works for clean files in your own layout.

Supplier files are rarely clean. Each supplier has its own columns, units and naming. Someone reshapes every file in Excel, loads it, then fixes what did not map. With ten suppliers that is a chore. With two hundred it is a full-time job.

More channels: marketplaces, B2B, print

Maropost has fields for the channels it runs, such as a separate eBay description. The pressure comes from channels it does not run. Think of a separate B2B portal, a dealer data feed, a print catalogue or a retailer’s supplier template. Each wants different attributes, lengths and image specs. Maropost is not designed to hold and validate a different output for each of them.

Signs you need a PIM alongside Maropost

These are the signals we see most often.

• You have more than about 5,000 SKUs, or the range is growing fast.
• More than 20 suppliers send data, each in their own format.
• New products wait weeks to go live because of data, not stock.
• A master spreadsheet outside Maropost holds the real attributes.
• Three or more channels beyond your webstore need product data.
• Variants are built by hand from supplier files.

None of these thresholds is a hard line. A catalogue of 3,000 technical SKUs with 40 attributes each can need a PIM sooner than 10,000 simple ones. What matters is how much of your team’s week goes on moving and fixing data rather than selling.

If two or more are true, it is worth scoping a PIM properly. Our PIM selection work starts from your catalogue and channels, not from a vendor shortlist. If none are true, keep investing in Maropost.

How does a PIM connect to Maropost?

Through the Maropost API, either directly or via a connector built on it. Every call is an HTTPS POST to a fixed endpoint on your store’s domain, with the action named in a header. Requests and responses can be XML or JSON.

For products, AddItem creates records and UpdateItem edits them. GetItem reads them, with filters such as ParentSKU and DateUpdatedFrom. A connector, whether from the PIM vendor or a middleware provider, calls the same API. Check what it maps before you buy: specifics, parent SKU, images and categories. Ask how it handles a rejected record, because a silent failure means a product that never reaches the webstore.

The bigger decision is ownership. Each field needs one owner.

System	Owns
PIM	Names, descriptions, attributes and specifics, images, categories, parent and child structure.
ERP	Cost, price, stock.
Maropost	Orders, customers, promotions, channel listing settings.

Then set sync timing. Content moves on publish or in a scheduled batch. Price and stock move often, usually from the ERP. Maropost’s developer documentation lists order notifications as its webhook type, so product updates are normally pushed from the PIM. Maropost also notes that parent and child links refresh when its Inventory Cache runs, every six hours. Plan launches of new variant families around that.

We design this through our integrations practice as part of PIM implementation, so field ownership is agreed before anyone writes code.

Cleaning up a Maropost export before you migrate

Start with a full export, keyed on SKU. Then fix five things before any data touches the PIM.

• Duplicates. The same product often sits under two SKUs after a supplier change or a relisting. Pick the survivor and retire the other.
• Variant structures. Some families are built as variants. Others are standalone products with the colour in the name. Map every parent and its variant axes.
• Specifics stuck in descriptions. Dimensions, wattage and materials hide in HTML descriptions. Maropost’s own guide to importing from BigCommerce shows the same issue: variation specifics in product names must be split out before they map. Extract them into attributes.
• SKU format. The API caps SKU at 25 characters. If your PIM or ERP uses longer codes, agree the mapping before the first sync.
• Image naming. Files called IMG_0042.jpg tell you nothing. Rename to a SKU-based pattern and decide which images belong to the parent and which to each child.

Which PIMs work with Maropost?

Any PIM with a sound API can feed Maropost. Integration effort matters more than the logo. Ask five questions:

• Is there a connector, and who maintains it?
• Does it handle parent SKUs and item specifics?
• Does it send images by URL or as files?
• How does it report failed records?
• Who fixes it when either API changes?

We implement several platforms, including Plytix, and the pattern is the same whichever storefront sits downstream. For Pacific Automation, an Australian industrial supplier, we built a taxonomy that classified every SKU. We then supported the selection and implementation of Plytix to feed their BigCommerce store. We do not rank vendors here. A vendor-neutral PIM selection tests each one against your data. Ask every shortlisted vendor to load a sample of your real variant families and push them to a Maropost test store. That shows the integration effort faster than any demo.

Frequently asked questions