This is a different problem from the existing “definitions persist after uninstall” threads. The persisting definitions aren’t just cosmetic - they’re actively **blocking merchants from updating their own products and variants** through any tool that round-trips metafields, and the merchant has no way to resolve it.
Setup
We’re a Shopify-managed-install app that declares product and variant metafield definitions in shopify.app.toml under the reserved `$app:…` namespace. Standard, documented pattern, e.g.:
[variant.metafields.app.stock_status]
name = "Stock status"
type = "single_line_text_field"
[product.metafields.app.tracked]
name = "Tracked"
type = "boolean"
Shopify provisions these on install, scoped to `app–{app-id}–{key}`, with write access locked to our app.
The problem
After a merchant uninstalls the app:
1. Shopify leaves the definitions on the store (already a known issue).
2. The values are still attached to every product/variant they were ever written to.
3. The namespace is still locked to our (now-uninstalled) app, so **no one** can write to those keys - not the merchant, not other apps, not Shopify Admin, not CSV import, not the merchant’s PIM.
The downstream consequence: any third-party tool that updates a product or variant by reading the full record and writing it back — which is most PIMs, bulk editors, ERPs, CSV importers, and a lot of agency-written scripts — fails with:
Access to this namespace and key on Metafields for this resource type is not allowed.
…because the write payload contains our app-owned metafields. The merchant didn’t change them, didn’t ask for them, can’t remove them, and now can’t update barcodes/inventory/vendor/anything else on the product because the whole mutation rejects.
Real merchant impact
We’re getting support tickets like this from churned merchants:
“We tested your app but it didn’t quite do what we wanted so we uninstalled. Since then we’ve had issues updating product meta info including barcodes and stock numbers. Your app is still tracking stock ‘app–{id}.tracked’ and is stopping the info being updated on the products. Please can you fix the issue.”
We can’t fix it. They’ve uninstalled us. We have no API access to their store anymore. Shopify owns these definitions. The only “fix” we can offer is:
- Reinstall the app → ask us to manually run a deletion routine with `deleteAllAssociatedMetafields: true` → uninstall again. **Not a reasonable ask of a merchant who has already churned.**
- Reconfigure every third-party tool in their stack to strip our namespace out of every payload. **Also not reasonable, and most off-the-shelf tools don’t expose that knob.**
Either way the merchant is left with the impression that the uninstalled app is “still blocking” their store, which is bad for everyone - it reflects on Shopify as well as the partner app.
Why this is worse than the existing “definitions persist” threads
The other threads on this topic (e.g. the one from 2024 in Custom Data) focus on definitions cluttering the admin or blocking re-creation. The argument Shopify has given for not auto-cleaning on uninstall — *“merchants might still rely on the data”* — doesn’t apply here, because:
- The data is in an app-reserved namespace.
- Only the app can write to it.
- The app is gone.
- The data is, by definition, frozen and useless to the merchant.
- And worse: it’s actively breaking unrelated workflows.
It’s not “useful leftover data” — it’s a write-locked landmine on every product the app touched.
Asks for Shopify
In order of preference:
1. Auto-cleanup on uninstall. When an app is uninstalled, delete the metafield definitions it declared in `shopify.app.toml` under reserved app-owned namespaces, along with the associated values. They are not usable by anyone after uninstall.
2. Auto-deactivate, not delete. If full deletion is too aggressive, at minimum *deactivate* the definitions so writes from third-party tools don’t fail — treat the keys as read-only / silently dropped rather than rejected.
3. Merchant-facing cleanup UI. Give merchants a button in the admin under Settings → Custom data to remove leftover definitions belonging to uninstalled apps. Today they have no path at all.
4. Better error / partial-write semantics. Have product/variant mutations silently ignore writes to app-owned keys when the owning app is uninstalled, rather than rejecting the entire mutation. This alone would unblock the third-party tool problem even without cleanup.
What we’d like to know
- Has this been raised internally? Is there a known timeline?
- Is there a supported way for a partner app to proactively guard against this — e.g. a webhook on `app/uninstalled` that lets us run a cleanup mutation **before** our access is revoked? (We can register the webhook, but by the time it fires, our access token is typically already invalid for write operations.)
- Is there any merchant-side workaround we can give to churned merchants that doesn’t involve reinstalling our app?
Happy to share specific affected stores privately to anyone from the Shopify team who wants to look at it.
-–
References
