Configure Sanity CORS for Vercel deployment without preview URL

Your issue is a common challenge with Vercel preview deployments and CORS configuration. The problem is that Vercel generates unique URLs for each preview deployment, making it impossible to whitelist them all in advance.

For Production Deployments

Add your production domain to CORS origins in your Sanity project settings:

1. Go to manage.sanity.io
2. Select your project
3. Navigate to Settings > API > CORS Origins
4. Add your production domain with protocol: https://your-domain.com
5. Enable "Allow credentials" if you're using authentication tokens

For Preview Deployments

Since Vercel preview URLs are dynamically generated, here are your best options:

Option 1: Use Server-Side Data Fetching (Recommended) Instead of fetching from the browser (which triggers CORS), fetch data server-side where CORS doesn't apply:

• In Next.js App Router: Use Server Components or Server Actions
• In Next.js Pages Router: Use getServerSideProps or getStaticProps
• This works because server-to-server requests bypass CORS entirely

Your Sanity API token stays server-side and never exposes to the browser, which is more secure and performs better.

Option 2: Use a Wildcard Domain with Preview Deployment Suffix If you have a custom domain on Vercel, configure a Preview Deployment Suffix like preview.example.com. Then add a wildcard to your CORS origins:

• https://*.preview.example.com

This gives you a predictable pattern for all preview deployments.

Option 3: Add Vercel's Default Preview Domain Add Vercel's wildcard domain to CORS:

• https://*.vercel.app

⚠️ Note: This is less secure since it allows any Vercel-hosted site to access your data, but it works for development purposes.

Option 4: Use Vercel's Static Outbound IP Addresses If you're on Vercel's Enterprise plan, you can use static outbound IP addresses for serverless functions and configure IP allowlisting instead of CORS. However, this doesn't solve browser-based CORS issues.

Recommended Approach

For most projects, Option 1 (server-side fetching) is the best solution. It's more secure, performs better, and works seamlessly across all environments without any CORS configuration. The key insight is that CORS only affects browser requests—server-side requests to Sanity's API don't need CORS configuration at all.

If you absolutely need client-side queries (like for real-time updates with the Live Content API), combine server-side fetching for initial data with Option 2 (custom preview domain wildcard) for client-side updates.