1. Fetch a public API in the browser

The shortest path is a plain fetch against a public endpoint. CoinGecko still answers without a key on the simple price route:

const url = "https://api.coingecko.com/api/v3/simple/price"
  + "?ids=bitcoin,ethereum,solana&vs_currencies=usd&include_24hr_change=true";

const res = await fetch(url);
const data = await res.json();
// { bitcoin: { usd: 77642, usd_24h_change: 0.58 }, ... }

Rate limiting bit me first. The free tier counts calls per IP, and since each visitor brings their own IP, the ceiling is effectively per visitor. That holds until a dozen people behind one office network open a page that polls every five seconds. Poll once a minute at most, and stash the last response in sessionStorage so a reload does not spend a call.

Then there is the id mapping. The route wants CoinGecko ids rather than symbols, and solana only works because the two happen to match. MATIC is matic-network. UNI is uniswap. I ended up with a hardcoded lookup table, the sort of thing that quietly rots the day a project renames itself.

Cost: roughly 40 lines with the rendering, plus a table to maintain.

2. Proxy it through a function

If you need a key, or you want one cache shared by every visitor, put a function in front:

// netlify/functions/prices.js
let cache = { at: 0, body: null };

export default async () => {
  if (Date.now() - cache.at < 60_000) {
    return new Response(cache.body, { headers: { "content-type": "application/json" } });
  }
  const r = await fetch("https://api.coingecko.com/api/v3/simple/price?ids=bitcoin,ethereum&vs_currencies=usd");
  cache = { at: Date.now(), body: await r.text() };
  return new Response(cache.body, { headers: { "content-type": "application/json" } });
};

For a real app this is the answer. One upstream call a minute regardless of traffic, the key never reaches the browser, and you get to reshape the payload on the way out.

What tripped me up is that the in-memory cache only lives as long as the instance stays warm. A cold start pays the upstream call again, and several concurrent instances each keep their own copy, so the real rate is a multiple of what the code suggests. Move the cache into a KV store if that number has to be exact.

Cost: a function, a deploy target that runs one, and a cold start on the first request of the day.

3. Drop in a hosted widget

On a marketing page I stopped trying to own the data. A hosted ticker is one element and one script:

<div id="crypto-marquee" data-theme="dark" data-count="10"></div>
<script src="https://www.thecoinanalysis.com/widgets/crypto-marquee-widget.js"></script>

I settled on the marquee from The Coin Analysis, which asks for no key and no account. It weighs about 16 KB, takes its settings from data attributes, and renders a credit link back to the source. That last part is the deal you accept with any free widget.

Pasting someone else's script in took me less time than the three checks around it.

Content Security Policy. The tag fails silently when your policy leaves the host out of script-src. The widget also calls its own price endpoint, so connect-src needs the host too. If it injects styles, add style-src. If it loads token logos, add img-src.

Layout shift. The ticker renders once the script has loaded, and everything below it jumps down. Reserve the height yourself:

#crypto-marquee { min-height: 44px; }

Measure the rendered height once in devtools and hardcode it. On a page like that, it is the single biggest Cumulative Layout Shift win available.

Motion. A scrolling marquee is a vestibular trigger for some readers. Whatever you embed, wrap it:

@media (prefers-reduced-motion: reduce) {
  #crypto-marquee * { animation: none; }
}

That rule is the only lever you have from the outside, so check that the widget renders into ordinary DOM rather than a closed shadow root before you commit to it.

What I would pick again

On a side project where the prices are decoration, the hosted widget wins on time and has never woken me up. When the number is the product, fetch it yourself and keep a function in front, because the day a free tier changes you want that failure landing in your logs instead of inside a script you do not control.

One habit carried across all three: render the stale value with a timestamp instead of a spinner. A price from four minutes ago still tells the reader something. A spinner only tells them the site is broken.

The numbers below come from The Coin Analysis public price API, which I picked because its free tier is exactly that strict. The ideas apply to any API where calls are the scarce resource.

One wide call beats twenty narrow ones

The instinct is to request one token, then the next, then the next. Three calls in, you are locked out for the hour.

Almost every list endpoint accepts a page size, and it is usually larger than you think. Here the whole universe comes back in a single request:

curl "https://www.thecoinanalysis.com/api/public/v1/prices?perPage=250&order=market_cap" \
  -H "x-api-key: $KEY"

That returned 220 tokens and "pages": 1 in the meta block. One call, the entire dataset, and filtering afterwards costs nothing. If you only care about a handful, ask for them by name rather than one at a time:

curl ".../prices?symbols=BTC,ETH,SOL" -H "x-api-key: $KEY"

Three tokens, one call. The rule is simple: every loop that contains an HTTP request is a bug waiting for a 429.

Refresh on a timer

Three calls per hour leaves one refresh every twenty minutes. Refreshing when a user asks means the third visitor of the hour gets an error page.

So the fetch belongs on a timer, and the request path only ever reads the last good value:

let cache = { at: 0, data: null };
const WINDOW = 20 * 60 * 1000;

async function prices() {
  if (Date.now() - cache.at < WINDOW && cache.data) return cache.data;
  const r = await fetch(`${BASE}/prices?perPage=250`, {
    headers: { "x-api-key": process.env.KEY },
  });
  if (r.status === 429) return cache.data;   // serve stale, never throw
  cache = { at: Date.now(), data: await r.json() };
  return cache.data;
}

The important line is the 429 branch. Stale prices are a small inconvenience. An exception in a request handler is a broken page.

The server already did the maths

The history endpoint returns the series and the derived numbers together:

{ "history": [ { "ts": "2026-08-16T15:00:00.000Z", "price": 63044 } ],
  "volatility": 0.5958, "maxDrawdown": 39.0, "athUsd": 126080 }

Volatility and maximum drawdown for that window, already computed. Pulling raw candles to calculate them yourself costs the same single call and adds code you now have to test. When a rate limit is tight, prefer the endpoint that answers the question over the one that returns the ingredients.

Where the 429 actually applies

This one cost me an afternoon. When the list endpoint was exhausted, I backed off everything. But the window is counted per endpoint, so detail and history were still available the whole time.

Track the reset per route:

const blocked = new Map();   // route -> timestamp

async function call(route) {
  if (Date.now() < (blocked.get(route) ?? 0)) throw new Error("cooling down");
  const r = await fetch(BASE + route, { headers: { "x-api-key": KEY } });
  if (r.status === 429) {
    blocked.set(route, Date.now() + 60 * 60 * 1000);
    throw new Error("rate limited");
  }
  return r.json();
}

Blanket backoff throws away quota you still have.

About that wildcard CORS header

The API answers with access-control-allow-origin: *, so the browser will happily call it. That does not mean you should: doing it from the front end ships your key to everyone who opens the devtools, and a shared key burns three requests in one page load.

Keep the key on a server or an edge function, cache there, and let the browser read your own endpoint. With a single call feeding every visitor for twenty minutes, the strict tier stops mattering.

What I would keep

A tight free tier turned out to be a good teacher. Batching instead of looping, caching on a timer, preferring the computed answer to the raw series, scoping the backoff to one route: none of that is specific to a stingy quota. It makes a generous API better too, which is the part I did not expect.

The endpoints and the free key are documented at The Coin Analysis if you want to try the same exercise.