Executive summary
- What: The metafieldInteger collection source condition types and inputs are removed from the GraphQL Admin API in version 2027-01, replaced by metafieldInt.
- Why: The value field on integer metafield conditions changes type from Int to String, aligning the Admin API with how the Storefront API has always represented metafield values.
- Who: Any app or internal service that creates, updates, or reads automated collection conditions based on integer metafields.
What changed
Four names are being replaced. CollectionSourceInclusionConditionMetafieldInteger becomes CollectionSourceInclusionConditionMetafieldInt, the matching relation enum follows the same rename, and the metafieldInteger field on both the create and update input objects becomes metafieldInt. The relation enum members themselves are unchanged, so EQUALS, GREATER_THAN, and LESS_THAN continue to mean what they did.
The substantive difference is the value type. Where you previously sent value as an integer literal, you now send it as a string: value: 2000 becomes value: "2000". Reads change in the same way, so an inline fragment on CollectionSourceInclusionConditionMetafieldInteger has to be rewritten against the Int type. On version 2026-10, metafieldInteger still works for writes, and integer metafield conditions already resolve to the new Int type when you read them. That overlap is the testing window.
Why it matters
This is a breaking change with a hard deadline, and the failure mode is unhelpfully split. Mutations that still send metafieldInteger on 2027-01 fail validation, which is loud and easy to catch. Queries that select the old type return errors, which in many codebases means a collection management screen or a sync job quietly stops returning conditions rather than raising an alarm.
The practical risk is scope discovery rather than code difficulty. The change itself is a rename plus a literal type adjustment, perhaps an hour of work in one place. Finding every place is the real task, because integer metafield conditions tend to accumulate across PIM sync jobs, merchandising tools, bulk collection scripts, and one-off operational utilities written years apart. Anything quoting numbers into a template string needs checking too, since a value that was valid as an integer may now be double quoted or coerced unexpectedly.
Merchants running merchandising automation across large catalogs should audit now while both forms work, rather than discovering the gaps during a version upgrade.
Role-specific impact
- Marketers: No change to how automated collections behave for buyers. Collection rules keep working, and the conditions you configure in the admin are unaffected.
- Developers: A rename across four types plus a literal type change from Int to String. Test on 2026-10 before upgrading, and grep for metafieldInteger across every repository that touches collections.
- Store admins: Watch for collection management tooling that stops displaying integer based rules after an upgrade, which is the most likely symptom of a missed read path.
Use-case example
Real-world scenario
An industrial distributor on Shopify Plus maintains about 240 automated collections keyed on integer metafields such as minimum order quantity, wattage, and load rating, all populated nightly from its PIM. The merchandising team had also built a bulk utility that rebuilt collection conditions after each catalog import. During a routine API version bump in a staging environment, the nightly job completed without error while the collection rebuild silently returned no conditions, and 31 collections emptied before anyone noticed. Auditing on 2026-10 first surfaced three separate code paths referencing metafieldInteger, two of which the team had forgotten existed. The migration took under a day once the inventory was complete.
Implementation checklist
- Search every repository, serverless function, and operational script for metafieldInteger, including string-built GraphQL queries.
- Rewrite writes to use metafieldInt and convert each value to a string literal.
- Rewrite reads so inline fragments target CollectionSourceInclusionConditionMetafieldInt.
- Confirm your relation enum usage is unchanged, since EQUALS, GREATER_THAN, and LESS_THAN still apply.
- Check any code that builds condition values numerically, so integers are serialized as strings without duplicate quoting.
- Test the full path on API version 2026-10, where both the old write form and the new read type are available.
- Add a regression check that asserts collection conditions are returned and non-empty after a rebuild, so a silent read failure cannot pass unnoticed.
- Upgrade to 2027-01 only once reads and writes are both verified.
FAQ
Q: How long do we have?
A: metafieldInteger keeps working on versions up to and including 2026-10 and is gone in 2027-01. Treat the 2026-10 window as your test period rather than your deadline.
Q: Do our existing collections break?
A: No. Collections and their rules continue to function. The removal affects how your code reads and writes those conditions through the API, not the collections themselves.
Resources
Collection source inclusion condition input reference
Need guidance? Talk to Makro.