Documents update in Studio but API returns old version with certain data

This is a tricky issue! Based on the symptoms you're describing - where one endpoint returns fresh data but query endpoints return stale data - you're likely hitting a CDN cache propagation issue combined with how different API endpoints interact with Sanity's caching infrastructure.

What's Happening

The two endpoints you're testing behave differently:

1. /v1/data/doc/ endpoint - This is a direct document fetch endpoint that appears to be retrieving fresher data
2. /v2021-10-21/data/query/ endpoint - This is the Query API endpoint that uses GROQ and is served through the API CDN

The Query API endpoints are served through Sanity's Live CDN, which uses intelligent caching with approximately 10-minute cache times. While the CDN should automatically handle cache invalidation when you publish changes, certain edge cases with document structure or content patterns can cause delays in cache propagation.

Why It Appears Random

The "problematic data" probably isn't inherently broken - instead, certain data patterns might be triggering edge cases in how the CDN invalidates and propagates updates. This could include:

• Large nested structures or arrays
• Complex reference chains
• Documents approaching size limits
• Specific field types or data patterns that affect cache keys

Immediate Solutions to Try

1. Add explicit perspective parameter

The query endpoint respects perspectives, which control what version of documents you see. Try adding perspective=raw to your query:

https://<project-id>.api.sanity.io/v2021-10-21/data/query/production?query=*[_id=="<doc-id>"]&perspective=raw

Available perspectives:

• raw - All documents including drafts
• published - Only published documents (may be the default depending on API version)
• previewDrafts - Prioritizes drafts over published

2. Bypass the CDN for testing

If you're using @sanity/client, disable CDN caching to rule out cache issues:

import {createClient} from '@sanity/client'

const client = createClient({
  projectId: 'your-project-id',
  dataset: 'production',
  apiVersion: '2024-01-01',
  useCdn: false, // Bypass CDN completely
})

This will hit the API directly without caching, helping you determine if it's truly a CDN propagation issue.

Debugging Steps

1. Check _updatedAt timestamps: Compare the _updatedAt field from both endpoints to confirm one is serving stale data

2. Look for draft documents: Check if drafts.<doc-id> versions exist that might be causing confusion:

   *[_id == "<doc-id>" || _id == "drafts.<doc-id>"]

3. Test with different API versions: Try the latest API version (e.g., v2025-02-19) to see if behavior differs

4. Document size check: Very large documents can sometimes cause issues - check if your "problematic" documents are significantly larger than others

5. Monitor cache headers: When fetching from the query endpoint, check the response headers for cache-related information (Age, Cache-Control, etc.)

Long-term Solution

Since this affects multiple documents in a seemingly random pattern, I'd recommend:

1. Contact Sanity Support: This sounds like it could be a CDN edge case that needs investigation. Provide them with:

   • Specific document IDs that reproduce the issue
   • The exact data patterns that trigger the problem
   • Timestamps showing when you publish vs when the cache updates
   • Your project ID and dataset name

2. Consider using useCdn: false for critical queries: If you need guaranteed fresh data for specific queries, bypass the CDN for those requests

3. Implement client-side cache busting: As a workaround, you could add a timestamp parameter to force fresh fetches when needed

The fact that the /data/doc/ endpoint works while the query endpoint doesn't strongly suggests this is related to how the CDN handles cache invalidation for GROQ queries versus direct document fetches. This is definitely worth reporting to Sanity support with specific reproduction cases.