Shopify metafields and your own data

Every business has data Shopify has no field for. A supplier code. A shelf location. A duty classification. The internal reference that ties a product to the way you actually buy it.

Metafields are Shopify's answer to that: custom fields you define and attach to products, variants, orders, customers and more, readable and writable through the API like anything else.

They solve a real problem, and they create a governance one.

What they are useful for

Four patterns that come up repeatedly in Malaysian retail and ecommerce.

Carrying your own identifiers. Your accounting system knows a product by one code and Shopify knows it by another. A metafield holding your internal code means an integration can join the two directly rather than matching on name or price, which is fragile — see the gateway reference that joins everything for the same principle on the payments side.

Holding attributes the storefront needs but Shopify has no field for. Dimensions, materials, compliance markings, care instructions.

Marking operational state. Which supplier a line comes from, whether an item is consignment stock, which location holds the master record.

Recording an integration's own bookkeeping. Whether an order has been posted to your accounts, and when. This is genuinely useful and it needs care, discussed below.

Where they go wrong

Metafields are easy to create and there is no natural moment at which anybody reviews them. Predictably, three things happen.

Nobody knows what exists. Fields accumulate over years, created by different apps and different people, and the store ends up with definitions nobody can account for. Removing one becomes risky because you cannot be sure nothing reads it.

The same concept exists twice. Two apps each create a supplier field with different names and different formats. Both are populated, inconsistently, and neither is authoritative.

They become a database rather than an annotation. The failure of scale. A metafield holding a small stable attribute is fine. A metafield holding a growing list, or a value updated many times a day, is using the wrong tool — and it will be slow, hard to query and impossible to report on properly.

The discipline that prevents all three is unglamorous: a written list of the metafields you use, what each is for, what format it holds, and which system owns it. One page, and almost nobody has it.

The ownership question

This is the part that matters most for an accounting integration, and it needs deciding rather than defaulting.

Who writes this field? If both Shopify and your accounting system can write the same metafield, they will eventually disagree, and there is no mechanism to resolve it. Whichever wrote last wins, which is not a rule anybody chose.

So each field needs a single owner, and the other system reads it. Where genuinely bidirectional behaviour is needed, the resolution rule has to be explicit and written down.

The pattern that works for repo-and-live systems generally applies here too: one side owns the value, the other side displays it, and the ownership is documented rather than remembered.

Using them for integration state, carefully

Writing back to Shopify to record that an order has been posted to your accounts is a common and reasonable use. It makes the state visible to anyone in the Shopify admin, which is helpful when someone asks whether an order has been through.

Two cautions.

It costs you write access. An integration that would otherwise be read-only now needs permission to write to orders, which is a broader permission than you might want to grant — see Shopify access scopes and protected customer data.

Shopify is not your audit trail. The authoritative record of what was posted and when belongs in your accounting system, where it cannot be edited from a storefront admin screen. A metafield is a convenience copy, and treating it as the record of truth means your audit trail is editable by anyone with store access — see keeping automated books healthy.

What to check before relying on them

Three practical points that affect whether a plan works.

Types are enforced. A metafield has a declared type, and that is a feature rather than an obstacle — it stops a number field filling up with text. Define the type deliberately rather than defaulting everything to a string.

They cost query budget like anything else. Requesting metafields on every product in a large catalogue adds cost to the query, so ask for the ones you need rather than all of them — see Shopify API rate limits and query cost.

They are exportable, but check. Before building a process on metafields, confirm they appear where you need them: in the export you plan to use, in the bulk operation result, and in whatever your integration reads. Discovering a field is absent from an export after building a monthly process on it is an avoidable afternoon.

Common questions

What are Shopify metafields used for?

Attaching your own data to store objects that Shopify has no built-in field for — internal product codes, supplier references, shelf locations, compliance attributes, or an integration's own record that an order has been posted. They are readable and writable through the API like any other field, which makes them the standard way to carry business-specific data alongside a Shopify store.

What is the main risk with metafields?

That nobody knows what exists. Fields accumulate over years, created by different apps and different people with no natural point of review, so the same concept ends up defined twice in different formats and removing anything becomes risky because you cannot be sure nothing reads it. A one-page written list of fields, purposes, formats and owners prevents all of it.

Should two systems write to the same metafield?

No, unless the resolution rule is explicit and documented. If both Shopify and an integration can write a field they will eventually disagree, and the outcome is simply whichever wrote last, which is not a rule anyone chose. Each field should have one owning system and the other should read it.

Can metafields be used as an audit trail?

They should not be. A metafield recording that an order was posted to the accounts is a useful convenience copy visible in the Shopify admin, but the authoritative record belongs in the accounting system where it cannot be edited from a storefront screen. Relying on the metafield makes the audit trail editable by anyone with store access.

Related: what the Shopify Admin API actually returns · Shopify access scopes and protected customer data · what it takes to build a Shopify connector