DEV Community: Ethan Cole

The crypto Fear & Greed API: strings, midnight timestamps and a week that is six days long

Ethan Cole — Fri, 25 Sep 2026 14:51:08 +0000

The crypto Fear & Greed Index from Alternative.me is one of those free endpoints everybody wires up in ten minutes. No key, no account, and it answers with access-control-allow-origin: *, so you can call it from the browser. I wired it up in ten minutes too, and then spent longer than that finding out why my numbers disagreed with theirs.

Here is the whole call:

const res = await fetch("https://api.alternative.me/fng/?limit=31");
const { data, metadata } = await res.json();

And here is what the first entry looked like on 25 September 2026:

{
  "value": "71",
  "value_classification": "Greed",
  "timestamp": "1790294400",
  "time_until_update": "33779"
}

Four things in that response tripped me up.

Every field is a string

value is "71", not 71. The timestamp and time_until_update are strings as well. Nothing breaks until you compare or sort, and then it breaks quietly: "9" > "71" is true in JavaScript, because strings compare character by character. Convert once, at the edge, and never touch the raw objects again.

async function fearGreed(days = 31) {
  const res = await fetch(`https://api.alternative.me/fng/?limit=${days}`);
  const { data, metadata } = await res.json();
  if (metadata.error) throw new Error(metadata.error);
  return data.map((d) => ({
    value: Number(d.value),
    label: d.value_classification,
    day: new Date(Number(d.timestamp) * 1000).toISOString().slice(0, 10),
  }));
}

The timestamp is midnight UTC, not the time of the reading

I pulled the full history with limit=0 and every one of the 3,155 timestamps falls exactly on 00:00 UTC. It names the day, not the moment the value was computed. Format it in local time and a reader in New York sees the wrong date: 1790294400 is 25 September in UTC and 24 September in America/New_York. If you display the date, pass timeZone: "UTC", or keep the day string from the function above.

time_until_update only works in the default format

The newest entry carries time_until_update, the number of seconds until the next refresh, which is handy for cache headers. Ask for readable dates with date_format=world and the timestamp becomes "25-09-2026", while time_until_update turns into "-1790260597". It is computed from the timestamp field, so once that field is a date string the result is garbage. Read it from a call without date_format, or ignore it and refresh a little after midnight UTC.

The history has holes, and indexes do not know about them

limit=0 returned 3,155 days, from 1 February 2018 to 25 September 2026. That span has 3,159 days. Four are missing: 14 to 16 April 2018 and 26 October 2024.

That matters the moment you compute "a week ago" by position. Counting back through an array assumes one entry per day, so any window that crosses a gap drifts by a day. Positions also invite an off by one of your own. I first built "a week ago" as history[history.length - 7] on a 30 item list reversed to oldest first, and that is six days back, not seven. The oldest item of a 30 item list is 29 days old, not a month. Both figures were plausible, and both were a day short.

Looking values up by date fixes both problems at once:

const series = await fearGreed(31);
const byDay = new Map(series.map((d) => [d.day, d.value]));

function daysAgo(n, from = series[0].day) {
  const t = new Date(`${from}T00:00:00Z`);
  t.setUTCDate(t.getUTCDate() - n);
  return byDay.get(t.toISOString().slice(0, 10)) ?? null;
}

daysAgo(7);  // 56 on 25 September 2026
daysAgo(30); // 65

A missing day now returns null instead of silently borrowing its neighbour, and you can decide what to show. Note that you need limit=31 for a value 30 days back, not 30.

One condition before you ship it

Alternative.me lets you use the data commercially, but only with the attribution placed right next to where you display it. That is one line of markup, and it is easy to forget when the widget works on the first try.

If you want to compare your numbers against a finished page, this fear and greed index chart reads the same endpoint and shows the week and month values alongside a 30 day history. On any given day, your daysAgo(7) and daysAgo(30) should match what it shows.

The last point of a downsampled price series is not "now"

Ethan Cole — Tue, 22 Sep 2026 10:54:45 +0000

I put a one year bitcoin chart on a page last week and labelled it with the price of its last point. That number was out by nearly ten per cent, and the response had been telling me so the whole time.

Here is the endpoint I was using. It is a free crypto price API, three requests an hour per endpoint, key in a header.

const res = await fetch(
  "https://www.thecoinanalysis.com/api/public/v1/prices/BTC/history?days=365&maxPoints=100",
  { headers: { "x-api-key": KEY } }
);
const { data } = await res.json();
const series = data.BTC.history;   // [{ ts, price, pctChange }, ...]

days is how far back to go, maxPoints is how many points you want out. Reasonable knobs. What I did not think through is what has to happen between them.

The tail is missing

Asking for a year at 100 points, today, the series runs from 20 January to 13 September. Today is 22 September. The last point on my chart was nine days old.

series.at(-1);        // { ts: "2026-09-13T21:00:00.000Z", price: 77313 }
data.BTC.currentPrice; // 85869

Eight and a half thousand dollars between the point I was labelling and the price a user could go and check. Just under ten per cent.

Ask for 500 points instead and the same call ends on 20 September, two days back rather than nine. So the gap is not a bug to route around, it is a function of how coarse a series you asked for. The coarser the buckets, the further from the present the last full bucket sits.

The gaps are not even either

I assumed a downsampled series was regularly spaced, because that is what the word suggests and what a naive implementation does. It is not, at least not here:

maxPoints	points	median gap	largest gap
100	100	11.0 h	261 h
500	500	2.25 h	72 h

Eleven days between two adjacent points at the coarse setting. Anything I compute from neighbouring points, a slope, a 24 hour change, a rate of anything, is computed over an interval I did not choose and cannot see without checking the timestamps myself.

And a year is not always a year

The same response starts on 20 January 2026 whichever resolution I ask for. That is about 245 days, not 365. The series starts where the data starts, and days is a ceiling rather than a promise. Worth an assertion if your axis labels are generated from the request rather than the response:

const span = (new Date(series.at(-1).ts) - new Date(series[0].ts)) / 864e5;
// 236 days at maxPoints=100, not 365

What I do now

Three rules, and none of them are specific to this API. Any endpoint that hands you a series plus a summary is doing the same thing.

Take headline numbers from the summary, not from the series. The response carries currentPrice beside the history precisely because the two answer different questions. The series answers "what shape was this", the summary answers "where is it now".

Never compute a rate from adjacent points without reading the timestamps. If you want a 24 hour change, find the point nearest 24 hours back and use its actual distance, or take the change from a field that was computed upstream on the full data.

Draw the gap instead of hiding it. If the last point is materially older than the bucket size, I plot the live price as a separate marker rather than extending the line to it. A line that runs to the right edge is a claim that you have data at the right edge.

The wider lesson is the one I keep relearning: the shape you receive is not the data, it is a rendering of the data chosen by a parameter you passed. Details of this one are at https://www.thecoinanalysis.com/developers, but the failure is portable.

The OpenAPI spec typed my requests and left the responses to me

Ethan Cole — Sat, 19 Sep 2026 21:32:43 +0000

I wired up a small public crypto price API last week and did the thing you are supposed to do: fetched its OpenAPI document and generated a client instead of hand-rolling fetch calls.

Half of it worked beautifully. The other half taught me something about what these documents usually contain.

What the spec gave me

The document is small, four operations, and the parameters are described properly:

{
  "name": "days",
  "in": "query",
  "schema": { "type": "integer", "default": 30, "maximum": 365 }
}

That one object is worth more than it looks. My generated client knows days is an integer, knows it defaults to 30, and knows 400 is out of range. The same goes for maxPoints, capped at 500, and perPage, capped at 250. Authentication is in there too, an apiKey in the x-api-key header, so the client wires the header itself rather than leaving me to remember it.

Requests, in other words, are a solved problem. I cannot send a malformed one without the compiler objecting first.

What it did not give me

Here is a complete response definition from the same document:

"responses": {
  "200": { "description": "Historical price series" },
  "401": { "description": "Missing or invalid API key" },
  "404": { "description": "Token not found" },
  "429": { "description": "Rate limit exceeded" }
}

A description, and nothing else. No schema, and components.schemas is empty. So the generated client hands me back unknown for the only part of the exchange I actually consume.

This is not a criticism of one API. Go and read the specs of the services you use. Parameters described, responses hand-waved, is the ordinary state of the art, and the reason is not laziness. Describing a request is describing four or five scalars you already validate. Describing a response means modelling every nested object you return and keeping that model true for as long as the endpoint lives.

What I do about it now

I stopped trying to get one artefact to do both jobs.

The generated client handles the request side, because that part of the spec is real. For responses I make one live call, look at what comes back, and write the type by hand:

import { z } from "zod";

const PricePoint = z.object({
  ts: z.string(),
  price: z.number(),
  pctChange: z.number(),
});

const History = z.object({
  meta: z.object({
    symbols: z.array(z.string()),
    days: z.number(),
    maxPoints: z.number(),
  }),
  data: z.record(z.object({
    history: z.array(PricePoint),
    volatility: z.number(),
    maxDrawdown: z.number(),
  })),
});

type History = z.infer<typeof History>;

Writing it as a schema rather than a bare type costs nothing extra and buys the part I used to skip, which is validating at the boundary rather than trusting either source:

const parsed = History.safeParse(await res.json());
if (!parsed.success) {
  // the shape moved; fail here, loudly, not three layers in
  throw new Error(`unexpected response: ${parsed.error.message}`);
}

A hand-written type is a guess about today. A runtime check is what tells you the guess has expired. Generated types give you neither, because unknown cannot be wrong.

The test I apply now

Before I commit to an API I ask two questions of its document. Does it stop me sending a bad request? Usually yes. Does it tell me the shape of what comes back? Usually no, and that is the half I have to own.

The API above is The Coin Analysis, free, three requests an hour per endpoint on the free tier, which is another thing worth knowing before you build a polling loop around it. But the point is not that one. Open the spec of whatever you are about to integrate and scroll to responses. You will learn in ten seconds how much work is still yours.

Three requests per hour: what a strict free tier taught me

Ethan Cole — Tue, 15 Sep 2026 13:19:42 +0000

Most "free tier" API posts assume a generous budget. This one is about the
other case: an API that allows three requests per hour, per endpoint. I have
been building a small crypto dashboard against one of those, and the limit
changed how I write client code more than any performance trick ever has.

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.

A live crypto price ticker on a static site, three ways

Ethan Cole — Mon, 14 Sep 2026 03:57:43 +0000

I run a small static site on Netlify and wanted a scrolling price ticker across the top. No build step, no server, and ideally no signup. Here is what I tried and where each one hurt.

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.