client.fetch in custom validation rules and API request impact

Not a dumb question at all! Yes, using client.fetch() inside a custom validation rule is technically possible, but there are important considerations:

Does it count as an API request?

Yes, absolutely. When you use client.fetch() (typically accessed via getClient() from the validation context), it makes a real API request to your Content Lake. Each of these requests counts toward your project's API usage and is subject to rate limits.

According to Sanity's technical limits documentation, there are several rate limits in place:

• Per IP limits: 500 req/s for global API calls, 25 req/s for mutations
• Concurrent limits: 500 concurrent queries per dataset, 100 concurrent mutations per dataset

Should you do it?

While it works, you should be very cautious about this approach:

1. Performance impact: As you've noticed, validation rules can fire multiple times during editing - on every keystroke, field change, or document update. This means you could be making dozens or hundreds of API requests during a single editing session, which will:

   • Slow down the editing experience significantly
   • Consume your API quota quickly
   • Potentially hit rate limits (especially the 500 req/s global limit or 500 concurrent queries limit)

2. Better alternatives:

   • Debounce your validation: If you must fetch data, consider implementing debouncing so the API call only happens after the user stops typing for a moment
   • Use initialValue: If you're validating against relatively static data, consider fetching it once and storing it in your schema or plugin configuration
   • Client-side caching: Cache the results of your fetch calls to avoid redundant requests
   • Move validation elsewhere: For complex validation requiring external data, consider using Sanity Functions with event handlers that validate on save/publish rather than in real-time. Functions are the modern, recommended approach for this kind of workflow automation - they're serverless, have native integration with Sanity, and can react to document changes without impacting the editing experience.

If you must use it:

validation: Rule => Rule.custom(async (value, context) => {
  const client = context.getClient({apiVersion: '2024-01-01'})
  // This WILL count as an API request and affect your rate limits
  const result = await client.fetch('*[_type == "reference"][0]')
  
  if (/* your validation logic */) {
    return true
  }
  return 'Validation error message'
})

The general recommendation is to keep validation rules lightweight and avoid external API calls when possible. Real-time validation should be fast and responsive for a good editing experience. If you need complex validation with data fetching, consider moving that logic to a Sanity Function that runs on document save/publish events instead.