Shopify metafields can hold the structured data a configurable product needs. Each field needs a clear meaning, a clear owner and a plan for missing or changed values.
Discuss your projectSee selected work
Metafields do not automatically create a rules engine. They also do not validate a customer’s order. This guide gives an original data contract example and a small local checker for that example. Use it as a planning aid. It is not a finished Shopify build.
Product options can easily end up in a text box, a note or a copied spreadsheet. This guide shows a cleaner way: plan the data first, then decide how Shopify should store it.
Start with typed definitions
Shopify gives metafields defined data types, including text, numbers, JSON and references. The type describes how a value is stored and validated by the platform. Choose each type for the meaning the field needs. Avoid storing every value as an unstructured text string.
Name each field in plain words. A good name tells the next person what the value means. A vague name, such as “info” or “data”, causes confusion later.
For a finish catalogue, a stable identifier and a readable label have different jobs. A label can change or be translated. The identifier should keep its meaning in saved configurations and in any mapping to commercial records. A colour swatch describes an interface sample. It is not an authoritative measurement of a physical material. Do not use it to match a real paint, fabric or stone.
An original finish contract
The example below is application-level JSON that could inform a metafield design. It is not a complete Shopify API request or a platform-native schema. It contains a version and two fictional finishes. The checker validates only the small contract described here. No data is uploaded or saved.
Choose Check example contract to review the JSON.
Metafields or metaobjects?
Metafields and metaobjects both store structured data in Shopify. They suit different jobs. The choice matters for a configurator, because the same values are often reused across products.
In general terms, a metafield holds a value for a single resource, such as one product. A metaobject lets you define a reusable structured entry. Several products can then reference that same entry.
A finish is a good test case. If many products offer the same finish, copying its label and swatch into each product invites drift. Someone changes the label on one product and forgets the others. A shared entry keeps one definition. Products point to it instead.
Use this simple test. Ask whether the value belongs to one product or to many. A value for one product can often stay as a metafield. A value shared across products may suit a reusable entry better.
This page does not give full setup steps. Check Shopify’s current documentation before you design the model. Setup steps and access rules can change over time. Whichever structure you choose, keep the identifier stable and the label separate.
How a configurator reads the data
How the data reaches the interface depends on the storefront. The routes work in different ways. Pick the route first, then plan how the values reach the browser. If the number of options is the problem rather than the data, see how to get past Shopify’s variant limit and option apps versus a custom build.
In a Shopify-hosted theme, Liquid can read metafield values when the page is built. The theme can then pass those values to the configurator script. This can keep the page simple, but it ties the data to the theme. Check the Liquid reference for the objects you need.
A custom storefront may instead request the values through Shopify’s Storefront API and build the interface from the response. Check the current Storefront API documentation to confirm how each field is exposed before you rely on it.
Define the contract once, then read it through the route your store uses. Do not write two separate versions of the same rules. Keep the cart work separate. The Shopify configurator integration guide covers the link from selection to cart.
Define the fields around their consumers
Start with the consumer of each field. A field earns its place when something uses it. A field with no consumer is clutter. Then decide what the application does when the value is missing or wrong.
| Information | Consumer | Failure policy to define |
|---|---|---|
| Model or asset reference | Viewer loader | Useful image fallback if the asset is missing |
| Finish identities and labels | Option interface and summary | Reject or explain unknown identities |
| Compatibility policy version | Rules and saved-state handling | Revalidate an older configuration |
| Commercial product mapping | Cart or quote integration | Do not confirm an unmapped item |
Keep a compact data dictionary with type, unit, owner and examples for every field. The dictionary can be a simple document. Its job is to stop guesswork. If the data is shared across many products, investigate an appropriate reusable reference structure. Avoid copying an opaque JSON document into every item.
Test the data boundary
Remove a required value, duplicate a finish ID and supply an older schema version. Confirm that the interface gives a useful result. It should not silently show the wrong finish. Test the permissions and availability of any data needed by the chosen storefront route.
Then test the commercial mapping separately. A valid finish document does not prove that a submitted choice resolves to an available variant or an accepted custom specification. Keep the authoritative validation in the order or quote process.
Write down the expected result for each test before you run it. That makes the outcome easier to judge. An unexpected result then shows up clearly, rather than looking normal.
A simple order of work
Work through the data in a clear order. This saves time and rework later.
- List the choices a customer can make.
- Note who uses each value, such as the viewer, the cart or the warehouse.
- Choose a type and a plain name for each field.
- Write the version number and the failure rules.
- Test the contract with the checker, then test it in your own store.
Skipping the first two steps tends to create messy data. Fields appear that nobody needs, and nobody owns the values that matter.
Common mistakes
Watch for these mistakes when you design configurator data.
- Using labels as IDs. A label can change or be translated. Saved configurations then point at text rather than a stable identity.
- Leaving JSON unversioned. Without a version, you cannot tell which rules a saved configuration was made under.
- Copying the same JSON into every product. One change then means many edits, and the copies drift apart.
- Trusting front-end data for price. Anyone can change what a browser sends. Confirm the price in the order or quote process, not in the browser.
About this work
I am an independent designer-developer based in Manchester, working across the UK. I led development of the Praxis Digital 3D configurator platform, used by 20+ UK businesses from 2021 to 2025. I build browser-based configurators around the buying journey and the systems behind it. The data work is part of that job. A configurator is only as good as the records behind it.
Explore the examples and next steps
Explore the working option journeys or document a range using the configurator brief. For the catalogue side, read the configurator product data guide. For wider context, see the product configurator page.
If you want help shaping this for your products, get in touch. Shopify work is also covered on my Shopify developer page.
Reference: Shopify’s metafield data types and Liquid metafield documentation. The example contract, checker and mapping worksheet are original project examples. Reviewed 13 October 2026.
For the equivalent on Magento and Adobe Commerce, see the Magento configurator guide.
For adding 3D product media and AR to Shopify, read the Shopify 3D models and AR guide.
Shopify metafields FAQ
Do metafields validate orders?
No. Metafields hold structured data. They do not create a rules engine. They also do not check a customer’s order. Keep the authoritative validation in the order or quote process.
When should I use metaobjects?
Consider metaobjects when several products need the same structured entry, such as a shared finish. Metafields suit a value that belongs to one resource. Check Shopify’s current documentation before you decide.
Does the checker send my data anywhere?
No. The checker validates only the small contract on this page. It uploads nothing and saves nothing. It is not a Shopify check, so run your own store tests as well.
The same metafields can power filters. See the product finder and filter design guide.