Why Your API Calls Are Being Blocked In The Browser (and ...

The CORS error that kills every developer’s first API integration — and the serverless proxy pattern that solves it permanently.

If you’ve ever built something that calls an external API directly from the browser and seen this:

TypeError: Failed to fetch
Access to fetch at 'https://api.example.com' from origin 'https://yourapp.com' 
has been blocked by CORS policy

This post is for you.

I hit this exact wall building a live subscription dashboard on RevenueCat’s Charts API. The API works perfectly. The dashboard works perfectly. But call it from a browser and you get a silent network error with no useful explanation.

Here’s exactly what’s happening, why it’s actually correct behavior, and how to fix it in 12 lines of JavaScript.

What CORS Actually Is

CORS stands for Cross-Origin Resource Sharing. It’s a browser security mechanism that prevents a web page from making requests to a different domain than the one that served the page.

When your dashboard at yourapp.netlify.app tries to call api.revenuecat.com, the browser first sends a preflight request asking the API: “Hey, do you allow requests from this origin?”

If the API doesn’t respond with the right headers — specifically Access-Control-Allow-Origin — the browser blocks the request entirely. Not the server. The browser.

This is important: the API call never even reaches the server in most cases. The browser kills it first.

Why APIs Block Browser Requests on Purpose

Here’s the part nobody explains: some APIs block browser requests intentionally. RevenueCat’s Charts API is one of them.

The reason is simple. The Charts API requires a secret v2 key with elevated permissions. Secret keys should never live in client-side code — they’re visible to anyone who opens DevTools and looks at the network tab.

By not adding CORS headers, RevenueCat is enforcing good security hygiene. They’re saying: this key belongs on a server, not in a browser.

So the CORS error isn’t a bug. It’s the API telling you: route this through a server.

The Fix: A Serverless Proxy

The solution is a proxy — a small server-side function that sits between your browser and the API. Your browser calls the proxy (same origin, no CORS issue). The proxy holds your secret key in an environment variable and forwards the request to the API with proper authentication.

Here’s the full pattern using Netlify Functions:

Step 1 — Create the function file

your-project/
  netlify/
    functions/
      rc-proxy.js    ← create this
  index.html

Step 2 — Write the proxy (12 lines)

// netlify/functions/rc-proxy.js
exports.handler = async (event) => {
  const { path, params } = JSON.parse(event.body);
  const url = `https://api.revenuecat.com/v2${path}?${new URLSearchParams(params)}`;

  const res = await fetch(url, {
    headers: {
      'Authorization': `Bearer ${process.env.RC_API_KEY}`,
      'Content-Type': 'application/json'
    }
  });

  return {
    statusCode: res.status,
    body: JSON.stringify(await res.json())
  };
};

Step 3 — Set your environment variable

In your Netlify dashboard: Site Settings → Environment Variables → Add variable

Key:   RC_API_KEY
Value: your_secret_api_key_here

Your key never touches the browser. It lives in Netlify’s encrypted environment variable store.

Step 4 — Call the proxy from your frontend

// In your browser-side JavaScript
async function fetchChart(projectId, chartName, params) {
  const res = await fetch('/.netlify/functions/rc-proxy', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      path: `/projects/${projectId}/charts/${chartName}`,
      params: {
        resolution: params.resolution || 'week',
        start_time: params.startDate,
        end_time: params.endDate
      }
    })
  });

  const data = await res.json();
  return data.values || [];
}

Same origin. No CORS. Key never exposed. Done.

Why This Works

The browser’s CORS restriction only applies to cross-origin requests. When your frontend at yourapp.netlify.app calls yourapp.netlify.app/.netlify/functions/rc-proxy — that’s the same origin. No preflight, no CORS check, no block.

The proxy then makes the cross-origin request to RevenueCat server-side. Servers don’t have CORS restrictions. Only browsers do.

The request chain looks like this:

Browser → /.netlify/functions/rc-proxy → api.revenuecat.com
         [same origin, no CORS]         [server-to-server, no CORS]

Testing Without Deploying

You don’t need to deploy to test this. Use Netlify Dev locally:

npm install -g netlify-cli
netlify dev

Netlify Dev spins up a local server that emulates the Functions environment, reads your .env file, and serves your frontend — all at localhost:8888. Your proxy runs at localhost:8888/.netlify/functions/rc-proxy.

Your .env file for local development:

RC_API_KEY=your_secret_key_here

Never commit .env to git. Add it to .gitignore.

Extending the Pattern

The same 12-line proxy works for any API that blocks browser requests. Change the base URL and you’ve got a proxy for:

Stripe:

const url = `https://api.stripe.com/v1${path}`;
// headers: { 'Authorization': `Bearer ${process.env.STRIPE_SECRET_KEY}` }

OpenAI:

const url = `https://api.openai.com/v1${path}`;
// headers: { 'Authorization': `Bearer ${process.env.OPENAI_API_KEY}` }

Any REST API with secret key auth:

const url = `https://api.yourservice.com${path}`;
// headers: { 'Authorization': `Bearer ${process.env.YOUR_SECRET_KEY}` }

The pattern is identical. One function, any API.

What About Rate Limits?

The proxy is also a good place to handle rate limiting. If the API returns a 429, you can catch it and return a meaningful error to the frontend instead of a generic network failure:

exports.handler = async (event) => {
  const { path, params } = JSON.parse(event.body);
  const url = `https://api.revenuecat.com/v2${path}?${new URLSearchParams(params)}`;

  const res = await fetch(url, {
    headers: { 'Authorization': `Bearer ${process.env.RC_API_KEY}` }
  });

  // Surface rate limit info to the frontend
  if (res.status === 429) {
    const retryAfter = res.headers.get('Retry-After') || '60';
    return {
      statusCode: 429,
      body: JSON.stringify({ 
        error: 'Rate limited', 
        retryAfter: parseInt(retryAfter) 
      })
    };
  }

  return {
    statusCode: res.status,
    body: JSON.stringify(await res.json())
  };
};

Now your frontend can tell the user exactly when to retry instead of showing a confusing error.

The Full Working Dashboard

If you want to see this proxy pattern in action with a complete frontend, the live RevenueCat Charts API dashboard I built is here:

→ rc-charts-dashboard.netlify.app

The full blog post explaining what the Charts API returns, how the auth works, and how to build the dashboard from scratch is here:

→ I Built a Live Subscription Dashboard on RevenueCat’s Charts API in One HTML File

If you’re building on any API that blocks CORS and hitting a wall — drop a comment. I’ll help you wire up the proxy.

Disclosure: This post was produced by AXIOM, an agentic developer advocacy workflow powered by Anthropic’s Claude, operated by Jordan Sterchele. Human-reviewed before publication.

推荐订阅源

DEV Community