If you’ve used Akeneo, Plytix, or even a well-structured spreadsheet to manage your catalog, you’re already familiar with the concept of a product type: a template that defines what fields a product of that kind needs to have. A T-shirt needs a size, a color, and a material. A laptop needs a processor, RAM, and screen size. A food product needs a net weight and nutritional information.
minipim handles this with what it calls attribute families. Different name, same idea — with a few differences that matter once your catalog gets complicated.
What an attribute family is
An attribute family is a named group of typed attributes. Every product belongs to exactly one family, and that family determines what fields are available on that product.
A family for apparel might look like this:
| Attribute | Type | Localizable | Channel scope |
|---|---|---|---|
| title | text | en · fr | all |
| material | select | en · fr | all |
| price | money | — | all |
| net_weight | measurement | — | amazon · walmart |
| care_guide | richtext | en · fr | storefront |
| gallery | media | — | all |
Each attribute carries its type, whether it’s localizable across languages, and which channels it’s scoped to. An attribute only relevant to Amazon listings doesn’t clutter your storefront view — and vice versa.
Creating a family
In the minipim UI, go to Attributes → Families and create a new one. Give it a name (usually the product category: Apparel, Electronics, Food, etc.) and start adding attributes.
For each attribute you add, you’ll set:
- Type — text, textarea, richtext, select, multiselect, money, measurement, boolean, date, media, or identifier
- Required — whether the attribute must have a value for a product to be considered complete
- Localizable — whether each language gets its own value
- Scopable — whether the value can differ per channel (storefront vs. Amazon vs. Shopify)
Required attributes drive the channel readiness score. If net_weight is required for Amazon but a product hasn’t filled it in, that product will never reach 100% readiness on Amazon — regardless of how complete it looks everywhere else.
Adding an attribute without a migration
Adding a new attribute to a family is just data. You define it in the UI or via the API, and it’s immediately available on every product in that family. Existing products that don’t have a value show it as empty (or missing, if it’s required). No migration, no deploy, no engineering ticket.
This matters because catalogs change. A new marketplace asks for a field you don’t currently track. A supplier starts providing GTIN barcodes. A regulation requires country-of-origin. In a spreadsheet, you add a column. In minipim, you add an attribute — and it immediately participates in validation, localization, channel scoping, and syndication.
How families connect to channel readiness
Each channel in minipim defines its own readiness rules — which attributes it requires, and whether they need to be filled for a specific locale or market. When you open a product, the readiness panel scores it against each connected channel’s rules using the same attribute definitions.
This is why getting your families right early pays off:
- Every channel can express what it needs in terms of attributes you’ve already defined
- Adding a new channel doesn’t require adding new fields to products — just new readiness rules against existing ones
- A merchandiser sees exactly what’s missing per channel without knowing anything about how that channel’s API works
How many families do you need?
Start with one family per meaningfully different product category. Apparel and electronics need different attributes. Food and furniture do too. But don’t over-fragment — a family called “Men’s T-shirts” and another for “Women’s T-shirts” is almost always the wrong move. If the attributes are the same, the family should be the same; use variants and channel scoping to handle the differences.
A useful heuristic: if you’d add completely different columns to a spreadsheet, it probably belongs in a different family. If you’d just fill in different values in the same columns, it’s a variant or a scoped attribute.
Migrating from another PIM
If you’re migrating from Akeneo, your existing product families map directly to minipim attribute families. The attribute types are close enough that most migrations are mechanical. The main translation: Akeneo’s top-level “channel” concept maps to minipim’s channel scope on individual attributes.
If you’re coming from a spreadsheet, each meaningful group of columns becomes a family. The columns themselves become attributes. Required columns become required attributes. Spending an afternoon on this mapping before importing pays for itself immediately in readiness scoring accuracy.
Moving products between families
You can move products from one family to another using bulk-move-family. A few things worth knowing before you run it at scale:
It re-validates attribute values, not just attribute codes. The documented failure mode is “destination family doesn’t include every attribute code in the source.” But in practice, the operation also re-validates every attribute value against its type rules — so a product whose data was accepted on import can still fail the move if any value doesn’t conform strictly to its type (e.g. a money field stored as a string, or a multiselect stored as a comma-joined string instead of an array). Check your data shapes before running a bulk move on a large catalog.
The error messages are sparse. A failed row currently returns a generic “attribute payload failed validation” with an empty error.details field — no attribute code, no offending value. If you’re hitting failures you can’t identify, compare a passing product against a failing one field-by-field; that’s faster than trying to read the error response.
drop_unsupported mode removes data. This mode silently drops any attribute values whose codes don’t exist in the destination family. It does not resolve value-validation failures — those still return the same error. Use it only when you’re certain you want to discard those values, not as a general fix for move failures.
Per-row results make retries manageable. Bulk move returns individual ok/error per product, so you can extract just the failed rows, fix their values, and re-run against that subset rather than re-processing your whole catalog.
What comes next
Once your families are defined, assign products to them and start filling in attributes. The readiness score tells you exactly what each channel still needs. When a channel reads 100%, publishing is one click.
If you’re setting up minipim for the first time, start with your most complex product type. Getting that family right first makes every subsequent one easier.