When I set out to build a gold value calculator—something users could use to check melt value by weight and purity—the first thing I had to figure out was where to get live gold prices. Most financial data APIs are paid or rate-limited, and I needed something that could handle production traffic without breaking.
The API Landscape
I looked at a few options:
- GoldAPI.io — straightforward REST endpoint, returns XAU (gold) price per troy ounce. Free tier: 100 requests/month. Paid plans scale from there.
- MetalpriceAPI — similar concept, supports multiple metals and currencies. Also has a free tier with monthly limits.
- Metals-API, Kitco, etc. — various pricing and feature sets.
I didn’t want to depend on a single provider. If one API went down or hit rate limits, the whole calculator would fail. So I designed a primary + fallback pattern: try GoldAPI first, then MetalpriceAPI if that failed.
Handling Different Response Formats
The tricky part was normalizing the responses. GoldAPI returns price per troy ounce directly. MetalpriceAPI’s “latest” endpoint uses rates.USDXAU for “1 ounce of XAU = $X” — but their docs warn that some setups return XAU (how much gold you get per $1) instead, so you have to check and use 1/XAU when needed. I ended up with a small adapter that maps both provider responses into a common structure: 24K price per gram, then derive 14K, 18K, etc. from purity ratios.
Server-Side Caching and SSR
Since gold prices don’t change every second, I used Next.js unstable_cache (or equivalent) to cache the API response on the server. That way:
- The first request populates the cache.
- Subsequent requests use cached data for a set TTL (e.g. 15 minutes).
- The initial HTML includes real prices for SEO and fast first paint, instead of empty placeholders.
The client then hydrates and can refetch on currency change or user interaction, but the initial load is server-rendered with real data.
Timeouts and Error Handling
Both APIs can be slow or unavailable. I added a 15-second timeout per request. If the primary provider times out or returns 429, we immediately try the fallback. If both fail, we fall back to a static price (with a clear “stale data” indicator) so the UI doesn’t break. Users still get a usable calculator; they just see that the price might be outdated.
What I’d Do Differently
- Rate limit awareness: On the free tier, 100 requests/month sounds like a lot until you realize server-side fetches + client refreshes can burn through that quickly. Caching is essential.
- Webhook or scheduled job: For a higher-traffic app, I’d consider a cron job that fetches prices periodically and stores them (e.g. in a DB or KV store), so the app reads from storage instead of calling external APIs on every request.
If you’re working with commodity or metal price APIs, the same patterns apply: normalize responses, cache aggressively, and always have a fallback. The calculator I built is live at MyGoldCalc if you want to see the result—supports grams, troy ounces, and common purities like 10K, 14K, 18K, 22K.
Top comments (0)