Get help on Discord

Sanity Connect: Can option values include variant IDs to distinguish duplicates?

2 replies
Last updated: Nov 30, 2025
Wondering if the Sanity Connect app would be able to give variant IDs for Option values. The current implementation is a bit problematic I think, seeing as if I had multiple Options and some of these Options had values with the same name, I’m not sure there is anyway to distinguish them? Unless index remains the same, but this feels very brittle to me.
e.g. with the below, this is tricky:


options:[
  {
    _key: 'Blue'
    _type: 'option'
    name: 'Blue'
    values: [
      'Signed',
      'Unsigned,
    ]
  },
  {
    _key: 'Red'
    _type: 'option'
    name: 'Red'
    values: [
      'Signed',
      'Unsigned,
    ]
  },
}
Whereas this would’ve been helpful:

options:[
  {
    _key: 'Blue'
    _type: 'option'
    name: 'Blue'
    values: [
      { 
        name: 'Signed', 
        variantId: 'schloop-doop-de-boop'
      },
      { 
        name: 'Unsigned', 
        variantId: 'turtle-burtle-plip-plop'
      },
    ]
  },
  {
    _key: 'Red'
    _type: 'option'
    name: 'Red'
    values: [
      { 
        name: 'Signed', 
        variantId: 'frump-de-bump-kerplunk'
      },
      { 
        name: 'Unsigned', 
        variantId: 'wiggle-fig-kerfloop'
      },
    ]
  },
}
AI Update

You're absolutely right to be concerned about this! The current implementation in Sanity Connect for Shopify does have this limitation, and your example perfectly illustrates the problem.

Looking at the reference documentation, product options in Sanity Connect are structured as simple string arrays:

"options": [
  {
    "_key": "Color",
    "_type": "option",
    "name": "Color",
    "values": ["Blue", "Ecru", "Pink"]
  }
]

The issue is that when you have multiple options with the same value names (like "Signed" and "Unsigned" appearing in both "Blue" and "Red" options), there's no unique identifier to distinguish them when you need to map them to specific variants.

The Current Workaround

The way to handle this currently is to use the variant documents themselves, which do contain the necessary information. Each variant document includes:

  • option1, option2, option3 fields with the actual option values
  • A unique id and gid (Shopify's global ID)
  • A reference back to the product via productId

When querying variants with Shopify's Storefront API using variantBySelectedOptions, you'd need to:

  1. Match the option values from your product's options array with the variant's option1, option2, option3 fields
  2. Use the position/index of options to determine which option value corresponds to which option field

This is indeed brittle, as you mentioned, because it relies on positional matching.

A Better Solution: Custom Sync Handlers

For your use case, you should consider implementing a custom sync handler. Custom sync handlers let you transform the data before it's saved to Sanity, so you could restructure the options to include variant IDs or create a more robust mapping structure.

With a custom handler, you could transform the data to something like your desired structure, or create a lookup table that maps option combinations to variant IDs directly on the product document.

The custom webhook payload includes ProductVariant objects with selectedOptions that show the name-value pairs, which you could use to build a more explicit mapping during sync.

This is definitely a valid pain point with the default sync structure, and using custom sync handlers is the recommended approach when the out-of-the-box schema doesn't quite fit your needs!

Show original thread
2 replies

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Get started for freeExplore the demo

Was this answer helpful?