Extended properties are the most underrated feature in Linnworks. They are simple name/value fields attached to each stock item, yet they quietly power product attributes, website data, courier rules and a whole ecosystem of third-party apps. If you have ever wondered what that Extended Properties tab is actually for, or why an app you installed suddenly filled it with rows, this guide covers the lot.
What extended properties actually are
Every stock item in Linnworks carries a core set of fixed fields: SKU, title, one retail price, one purchase price, weight, dimensions and so on. Those fields are rigid — you cannot add your own columns to them. Extended properties are the escape hatch. Each one is a free-form record with a property name, a value, and a type, and you can attach as many as you like to any item.
Because the schema is entirely up to you, extended properties end up doing very different jobs for different businesses. Three broad categories cover most real-world usage:
- Attributes. Product characteristics such as colour, material, country of origin or commodity codes. Useful for filtering, listings and customs paperwork.
- Web properties. Data destined for a connected website — long descriptions, meta keywords, category paths. Integrations read these when pushing products out.
- App data. Third-party tools commonly write their own rows here, because it is the only sanctioned place to store extra per-SKU data inside Linnworks itself. Tier prices are the classic example — more on that below.
Viewing and editing properties on a single item
Open any stock item and you will find the Extended Properties tab alongside the general details. From there you can add a row, rename a property, change its value or delete it. Edits save against the item immediately, and anything a third-party app wrote is sitting right there in plain sight — visible, editable and yours. That transparency matters: there is no hidden database you cannot inspect.
A word of caution, though. Because apps read these rows by property name, renaming a property an app depends on will usually break the link between the app and that item. If a row looks machine-written (a consistent prefix, a numeric value), check which tool owns it before touching the name.
Bulk editing and export
Editing one item at a time is fine for a handful of SKUs. At catalogue scale you have two native routes:
- Data import/export. Linnworks' CSV tooling can export stock items with their extended properties and import them back, one row per SKU. This is the standard way to populate hundreds of properties at once. It works, but the mapping step is unforgiving — a column mapped to the wrong field will silently overwrite good data with no undo. We cover the traps in detail in our guide to bulk price updates: CSV vs grid.
- The API. Extended properties have full API coverage, which is how apps read and write them. Bear in mind the API is rate-limited to roughly 150 calls per minute per token, so well-built tools batch their updates rather than firing one call per SKU.
Exportability is a genuinely important feature. Whatever lives in extended properties can be pulled out to CSV whenever you like, which means data stored there is never trapped.
Limits and gotchas
- No validation. Linnworks will happily accept a price of "abc" or a duplicate property name. Consistency is your job, or your app's job.
- Names are conventions, not schema. "Colour", "colour" and "Color" are three different properties. Pick a naming convention early and enforce it.
- They do not affect pricing or stock logic. An extended property called "Wholesale Price" is inert data until something — a listing template, an app, an order tool — reads it and acts on it.
- Bulk mistakes scale. Because import is row-per-SKU with silent overwrites, one bad mapping run can rewrite a property across the whole catalogue. Always export a backup first.
Why pricing apps store tier prices in extended properties
If you run trade or wholesale customers, you have hit the wall: Linnworks holds exactly one retail price per item, and there is no native concept of customer-specific or tiered pricing. Third-party pricing engines work around this by calculating tier prices externally and writing them back as extended properties — one property per tier, per SKU.
This design is deliberate, and it is the right one for sellers:
- Portability. Your trade prices live inside your own Linnworks account, not in a vendor's silo. Export them any time.
- No lock-in. Cancel the app and the properties remain. Your price list survives the tool that made it.
- Visibility. Staff can see every tier price on the item screen without logging into anything else.
- Interoperability. Order tools, invoice templates and website integrations can all read the same properties.
We have written a focused piece on exactly how this pattern works for pricing — see using extended properties for tier prices — and a broader look at running tiered pricing without spreadsheets.
Practical housekeeping tips
- Export your extended properties monthly as a backup, even if nothing changed.
- Document which properties are human-maintained and which belong to apps.
- Prefix your own custom properties (for example "GH_") so they never collide with app-owned rows.
- Audit for orphans occasionally — properties written by apps you no longer use.
If the reason you are reading about extended properties is wholesale pricing, that is exactly what we are building. B2B Price Tiers is coming very soon: unlimited named tiers, a formula engine, a spreadsheet-style grid, and two-way sync that writes every tier price back to Linnworks as native extended properties — portable, visible, no lock-in. Learn more at b2b-prices.mcp-g.com and register your interest to be first in line when it launches.