Sanity CMS integration - LaunchDarkly

This topic explains how to use the integration between LaunchDarkly and Sanity CMS. The integration connects LaunchDarkly feature flags to Sanity Studio so that content editors can manage A/B/n test variations on individual content fields directly inside Sanity, while LaunchDarkly handles experiment targeting and traffic allocation. Use the integration to:

Add A/B/n test variations to individual content fields in Sanity Studio
Sync feature flags and their variations automatically from LaunchDarkly
Let content editors author variant content without developer intervention
Serve personalized content based on LaunchDarkly targeting rules at runtime
Filter which flags appear in the Studio using LaunchDarkly tags

The integration stores variant content in Sanity entries alongside each field’s default value. Your application uses a LaunchDarkly SDK to evaluate the active variation and queries Sanity with that variation to retrieve the correct content.

How the integration works

The integration uses the @sanity/personalization-plugin, a Sanity Studio plugin that enables A/B/n experiments on individual content fields. When you install and configure the plugin, content editors can assign LaunchDarkly feature flags to fields and author variant content directly in the Studio. When configured, the plugin:

Registers new schema types for each field type you enable for experiments. For example, enabling the string type creates flagString and variantString types.
Fetches available feature flags and their variations from LaunchDarkly using a Reader API token you configure in the Studio
Lets editors assign a flag to a field, then author content for each variation
Stores the default value and all variant content on the Sanity entry

All flag targeting rules and traffic allocation remain managed in LaunchDarkly. The integration reads flags but does not create or modify them.

Prerequisites

To use the integration, you must have:

A Sanity Studio v3 project
A LaunchDarkly account with access to API tokens, projects, and environments
Node.js 18 or later
A LaunchDarkly API access token with the Reader role, or a custom role with read access to flags

Create or manage API access tokens on the Authorization page. To learn more, read API access tokens.

Set up the Sanity integration

Setting up the Sanity integration involves three steps:

Install the plugin
Configure the plugin
Enable experiment fields

After setup, content editors can add experiments to fields directly in Sanity Studio.

Install the plugin

To install the plugin in your Sanity Studio project, enter the following command in your terminal:

npm install @sanity/personalization-plugin

Configure the plugin

Before you configure the plugin, configure your LaunchDarkly flags with string variation types and descriptive variation names. You can also apply tags to filter which flags appear in the Studio. Here is an example flag configuration:

Flag key:   homepage-hero-experiment
Variations: control, treatment-a, treatment-b
Tags:       sanity-content

To configure the plugin in sanity.config.ts:

Import fieldLevelExperiments from @sanity/personalization-plugin/launchDarkly.
Add the plugin to your Sanity config and provide your LaunchDarkly project key.
Specify the field types you want to enable for experiments.
Optionally, provide tags to filter which flags appear in the Studio.

Here is an example sanity.config.ts:

import { defineConfig } from 'sanity'
import { fieldLevelExperiments } from '@sanity/personalization-plugin/launchDarkly'

export default defineConfig({
  // ... your existing Sanity config
  plugins: [
    // ... your other plugins
    fieldLevelExperiments({
      projectKey: process.env.SANITY_STUDIO_LAUNCHDARKLY_PROJECT_KEY!,
      fields: ['string', 'text', 'image'],
      // ... optional filter flags
      tags: ['sanity-content'],
    }),
  ],
})

Set the project key in your .env file as follows:

SANITY_STUDIO_LAUNCHDARKLY_PROJECT_KEY=your-project-key

The API token is stored securely in Sanity using @sanity/studio-secrets and is never exposed to your frontend application.

Expand plugin configuration options

Option	Type	Required	Description
`projectKey`	String	Yes	Your LaunchDarkly project key
`fields`	Array	Yes	Field types to enable for experiments. Accepts type name strings or complete field definitions.
`tags`	Array	No	Filter flags to only those with all specified tags

Enable experiment fields

The plugin registers new schema types for each field type you configure. For each type, the plugin creates two new types: one for the flag field and one for each variant entry.

Expand field type mappings

Original type	Flag type	Variant type
`string`	`flagString`	`variantString`
`text`	`flagText`	`variantText`
`image`	`flagImage`	`variantImage`
Custom types	`flag`	`variant`

To use experiment-enabled fields, replace the original field type with the corresponding flag type in your schema. Here is an example schema:

import { defineField, defineType } from 'sanity'

export const post = defineType({
  name: 'post',
  title: 'Post',
  type: 'document',
  fields: [
    defineField({
      name: 'title',
      title: 'Title',
      type: 'flagString', // Enables A/B/n testing on this field
    }),
    defineField({
      name: 'heroImage',
      title: 'Hero Image',
      type: 'flagImage', // Enables A/B/n testing on images
    }),
    defineField({
      name: 'excerpt',
      title: 'Excerpt',
      type: 'text', // Regular field, no experiments
    }),
  ],
})

Add experiments in Sanity Studio

After configuring the plugin and updating your schema, content editors can add experiments to fields directly in the Studio. To add an experiment to a field:

Open a document with experiment-enabled fields.
Enter your LaunchDarkly API token when prompted. The Studio stores this token securely. You only need to enter it once.
Select the three-dot field actions menu on an experiment-enabled field.
Select Add flag.
Choose a flag from the menu, which is populated from your LaunchDarkly project.
Add variant content using the quick-add buttons.
Use the Copy default button to duplicate the default field value to a variant as a starting point.

The Studio displays a visual distinction between the default content and each variant.

Stored fields and implementation

This section describes how the integration stores experiment data in Sanity and provides examples for retrieving variant content in your application.

Stored fields on entries

The integration stores the following data on each experiment-enabled field in Sanity:

Expand stored field properties

Property	Type	Description
`_type`	String	Schema type, such as `flagString`
`default`	Varies	The default/control content value
`active`	Boolean	Whether the experiment is active on this field
`flagId`	String	LaunchDarkly feature flag key
`variants`	Array	Array of variant content objects

For example, a flagString field with two variants is stored as in this example:

{
  "title": {
    "_type": "flagString",
    "default": "Welcome to Our Site",
    "active": true,
    "flagId": "homepage-hero-experiment",
    "variants": [
      {
        "_key": "abc123",
        "_type": "variantString",
        "flagId": "homepage-hero-experiment",
        "variantId": "control",
        "value": "Welcome to Our Site"
      },
      {
        "_key": "def456",
        "_type": "variantString",
        "flagId": "homepage-hero-experiment",
        "variantId": "treatment-a",
        "value": "Discover Something New"
      }
    ]
  }
}

Each variant object in the variants array contains:

Expand variant object properties

Property	Type	Description
`_key`	String	Unique key for the array element
`_type`	String	Schema type, such as `variantString`
`flagId`	String	LaunchDarkly feature flag key
`variantId`	String	LaunchDarkly variation value
`value`	Varies	The variant content value

Implementation examples

These examples show how to evaluate feature flags and retrieve the mapped variant content in an application.

Resolve variant content using GROQ

Use the coalesce function in GROQ (Graph-Relational Object Queries), Sanity’s query language, to retrieve the correct variant content for the active variation. If no variant matches, the query falls back to the default value. Here is an example of a GROQ query with variant resolution:

*[_type == "post" && slug.current == $slug][0] {
  "title": coalesce(
    title.variants[flagId == $flagKey && variantId == $variantId][0].value,
    title.default
  ),
  "heroImage": coalesce(
    heroImage.variants[flagId == $flagKey && variantId == $variantId][0].value,
    heroImage.default
  ),
  excerpt,
  slug
}

Evaluate a flag and fetch personalized content

This example shows how a Next.js application retrieves the active variation from LaunchDarkly and passes it to Sanity to fetch the matching content:

import { init, LDClient } from '@launchdarkly/node-server-sdk'

let client: LDClient | null = null

export async function getClient(): Promise<LDClient | null> {
  if (!client && process.env.LAUNCHDARKLY_SDK_KEY) {
    client = init(process.env.LAUNCHDARKLY_SDK_KEY)
    await client.waitForInitialization({ timeout: 10 })
  }
  return client
}

export async function getVariation(
  flagKey: string,
  context: { key: string; anonymous?: boolean }
): Promise<string> {
  const ldClient = await getClient()
  if (!ldClient) return 'control'

  const variation = await ldClient.variation(flagKey, context, 'control')
  return variation.toString()
}

import { sanityClient } from '@/lib/sanity'
import { getVariation } from '@/lib/launchdarkly'
import { cookies } from 'next/headers'

async function getPost(slug: string, variantId: string) {
  return sanityClient.fetch(
    `*[_type == "post" && slug.current == $slug][0] {
      "title": coalesce(
        title.variants[flagId == 'homepage-hero-experiment' && variantId == $variantId][0].value,
        title.default
      ),
      "heroImage": coalesce(
        heroImage.variants[flagId == 'homepage-hero-experiment' && variantId == $variantId][0].value,
        heroImage.default
      ),
      excerpt,
      content
    }`,
    { slug, variantId }
  )
}

export default async function PostPage({ params }: { params: { slug: string } }) {
  const cookieStore = cookies()
  const userId = cookieStore.get('user-id')?.value || 'anonymous'

  const variantId = await getVariation('homepage-hero-experiment', {
    key: userId,
    anonymous: true,
  })

  const post = await getPost(params.slug, variantId)

  return (
    <article>
      <h1>{post.title}</h1>
      {/* ... */}
    </article>
  )
}

Handle multiple flags

For documents with multiple experiment fields using different flags, pass each flag key and variant ID separately. Here is an example:

*[_type == "page"][0] {
  "headline": coalesce(
    headline.variants[flagId == $headlineFlag && variantId == $headlineVariant][0].value,
    headline.default
  ),
  "heroImage": coalesce(
    heroImage.variants[flagId == $heroFlag && variantId == $heroVariant][0].value,
    heroImage.default
  ),
  "ctaText": coalesce(
    ctaText.variants[flagId == $ctaFlag && variantId == $ctaVariant][0].value,
    ctaText.default
  )
}

Troubleshooting

If you encounter issues with the LaunchDarkly Sanity integration, try these solutions. If no flags appear when adding an experiment to a field:

Verify that your API token has read access to the selected project.
Confirm that projectKey in the plugin config matches your LaunchDarkly project key, not the SDK key.
Verify that the expected flags have all the specified tags applied in LaunchDarkly when using the tags option.
Refresh the Studio page to re-fetch flags from LaunchDarkly.

API token errors

If the Studio displays a token error or repeatedly prompts for a token:

Navigate to a document with experiment-enabled fields.
Enter a new valid LaunchDarkly API token when prompted. The old token is replaced.
Confirm that the token has Reader access or a custom role with read access to flags.

Variant content is not delivered correctly

If your application serves the default content instead of the expected variant:

Confirm that the variantId passed to your GROQ query matches the variation value defined in LaunchDarkly, not the variation name.
Verify that the Sanity document is published. Draft changes are not visible to your frontend.
Confirm that the flagId on the field matches the flag key in your GROQ query.
Clear any CDN caches on your frontend after publishing changes in Sanity.

Schema types are not available

If flagString or other flag types are not available in your schema, confirm that the field type is listed in the fields array in the plugin config. Then restart the Sanity Studio dev server after updating the plugin configuration.

​How the integration works

​Prerequisites

​Set up the Sanity integration

​Install the plugin

​Configure the plugin

​Enable experiment fields

​Add experiments in Sanity Studio

​Stored fields and implementation

​Stored fields on entries

​Implementation examples

​Resolve variant content using GROQ

​Evaluate a flag and fetch personalized content

​Handle multiple flags

​Troubleshooting

​Flags do not appear in the Studio menu

​API token errors

​Variant content is not delivered correctly

​Schema types are not available