How goldprice.dev prices gold in local currencies
How goldprice.dev combines USD metal prices with exchangerate.dev FX rates to serve local-currency gold prices without hiding freshness boundaries.
goldprice.dev and exchangerate.dev are sibling products operated by the same company. In production, goldprice.dev owns the metal-price contract while exchangerate.dev supplies the FX leg for supported floating currencies. The boundary matters: a local gold price contains two market observations, and one fresh leg cannot make the other fresh.
/v1/convert endpoint provides the one-call production path.computed_at and FX data_updated_at, timestamp, source, and market_session independently.The production boundary
goldprice.dev starts with a USD metal observation. exchangerate.dev provides the corresponding USD-to-local FX observation for supported floating currencies. goldprice.dev then owns the metal-specific conversion contract, including units, supported symbols, validation, and the final response.
This is a disclosed sibling integration, not an independent customer endorsement. Its value as a case study is operational: the FX API supplies a real production data leg, and the consuming product keeps responsibility for its own domain.
The conversion formula
Gold is commonly quoted as USD per troy ounce. A local display usually needs a currency amount per gram. Convert the weight first, then apply the USD exchange rate:
The weight constant is fixed. The two market inputs are not: both the gold quote and the FX rate have their own observation time and freshness rules.
The one-call production path
For callers, the production boundary is goldprice.dev `/v1/convert`. It combines the metal and FX legs behind one metal-aware endpoint and does not require an API key. This example requests the value of one gram of gold in Indonesian rupiah:
This path keeps the caller contract small: one request, one amount, one metal unit, and one target currency. Its single timestamp does not independently evidence both market legs, so consumers that must audit FX freshness should use the two-leg path below.
The auditable two-leg integration
Fetch both APIs when you need to retain each source timestamp, cache the inputs independently, or explain which leg is stale. goldprice.dev spot supplies USD gold per troy ounce; exchangerate.dev supplies the USD-to-local rate.
Why the services remain separate
The integration does not turn exchangerate.dev into the whole gold-pricing engine. It remains the FX layer. Keeping that boundary explicit prevents currency freshness, metal freshness, and product-specific conversion rules from collapsing into one ambiguous value.
- goldprice.dev can expose a small, metal-specific interface without making callers assemble the common path themselves.
- exchangerate.dev keeps a general FX contract that is useful outside the metals domain.
- Audit-sensitive consumers can retrieve and store both observations independently.
- Each service can report failures and freshness using the vocabulary of its own market data.
Handle stale or missing legs explicitly
A combined price should not survive if either input is missing, zero, non-numeric, or outside your product's accepted freshness window. Keep the last valid value only if the interface labels it with its original observation times.
- Check both HTTP responses before doing arithmetic.
- Reject non-finite or non-positive prices and rates.
- Set separate freshness thresholds for gold and FX.
- Treat
market_session: weekendas context, not as proof that a carried rate is current. - Log the currency pair and both underlying observation times with conversion errors.
Round for display, not during calculation
Keep full precision through the multiplication and let the display locale decide the final number of decimal places. Intl.NumberFormat handles currency symbols and grouping without changing the underlying value:
Use the result as an indicative value
A calculated market value is not the retail price of a coin or bar. Dealer premiums, taxes, fabrication, payment fees, and executable FX spreads are outside this formula. Label the output as indicative unless your application adds a real dealer quote and its commercial terms.
What this case study proves
goldprice.dev is first-party evidence that exchangerate.dev can supply the FX leg of a production pricing workflow. It is not independent social proof. The useful proof is narrower and reproducible: developers can call the same public products, preserve both observation times, and verify the arithmetic themselves. The published 31-currency gold study applies that method to every supported currency and shows the dated result table.