← All posts
Linnworks ops · 29 May 2026 · 4 min read

Storing tier prices in Linnworks extended properties: the pattern that keeps everything native

The moment tier prices live outside Linnworks — a spreadsheet, a separate app database — you own a synchronisation problem forever. There is a better home for them.

Extended properties, the underused feature

Every Linnworks stock item carries extended properties: named key-value fields that ride along with the item through the API and exports. Write TRADE, WHOLESALE and RRP prices as extended properties and the prices live where the products live.

Why native beats external

Anything that can read Linnworks can read the prices — order tools, reports, integrations, your own exports. There is no second system of record to reconcile, no "which one is right" argument, and if you ever stop using the pricing tool that wrote them, the data stays yours, in your Linnworks.

The workflow

Compute tier prices wherever the formula logic lives, then push the results into extended properties. Recalculate, push again. Downstream tools — like a POS applying a customer's tier at the counter — just read the property.

This is exactly how B2B Price Tiers works with Linnworks: sync catalogue down, push tier prices back as native extended properties. Your data, your Linnworks, no lock-in.

Questions, or want a tool we don't have yet? Email hello@grafto.co.uk — a real person replies.