What are extended properties in Linnworks?

Extended properties are free-form fields attached to each stock item, each with a property name, a value and a type. Because the core Linnworks item fields are fixed, they act as the escape hatch for storing custom per-SKU data such as attributes, web content or app data.

Can I bulk edit Linnworks extended properties?

Yes, via CSV data import/export or the API. CSV is the standard route for populating hundreds at once, but mapping a column to the wrong field silently overwrites good data with no undo, so export a backup first. The API is rate-limited to about 150 calls per minute.

Will renaming an extended property break anything?

It can. Apps read rows by property name, so renaming a property an app depends on usually breaks the link between the app and that item. If a row looks machine-written, check which tool owns it before changing the name.

Are extended properties safe to rely on for important data?

The data itself is portable and can be exported to CSV any time, so it is never trapped. However, Linnworks applies no validation and treats names as conventions rather than schema, so consistency and naming discipline are your responsibility.

Linnworks extended properties: the complete guide

Q: Why do pricing apps store tier prices in extended properties?

Linnworks holds only one retail price per item and has no native tiered pricing. Pricing engines calculate tier prices externally and write them back as extended properties, one per tier per SKU. This keeps your trade prices inside your own account, exportable and visible, with no vendor lock-in.

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.