A reproducible exchange-rate API freshness benchmark

An FX API freshness claim is only useful when the observation window, plan, pair, timestamp semantics, sample count, and exclusions are visible. This protocol publishes those rules before any provider result. Version 1.0 contains no ranking because the minimum evidence window has not yet been completed.

What this benchmark measures

The benchmark separates API response speed from data freshness. Response latency is the time between starting a request and receiving the complete response. Data age is the time between receiving that response and the provider-reported timestamp for the underlying rate. A fast CDN can return an old rate quickly, so the two measurements must never be merged.

The fixed protocol

• Measure EUR/USD in one direction at the precision each provider returns; do not round before change detection.
• Schedule one request every 60 seconds for at least seven calendar days, including five open-market days.
• Record the provider plan, authentication state, measurement region, parser version, and exact start and end times.
• Retain every scheduled observation, including HTTP errors, parse errors, missing timestamps, and timeouts.
• Do not publish a provider result until it contains at least 500 successful observations.
• Stay within each provider’s documented rate limits and terms; a provider is not eligible when measurement is not permitted.

The observation record

Store the raw rate and provider timestamp before computing summaries. The normalized record below is sufficient to reproduce each metric while preserving errors instead of silently dropping them.

{
  "provider": "example",
  "plan": "free",
  "pair": "EUR/USD",
  "request_started_at": "2026-07-16T09:00:00.000Z",
  "response_received_at": "2026-07-16T09:00:00.184Z",
  "http_status": 200,
  "rate": "1.16427",
  "provider_data_updated_at": "2026-07-16T08:59:31Z",
  "provider_source_label": "live",
  "provider_market_session_label": "open",
  "response_latency_ms": 184,
  "error_class": null
}

The timestamp rule

A provider is scorable for data age only when it exposes a parseable timestamp that describes the underlying rate. An HTTP Date header or the collector’s receive time does not qualify. If timestamp semantics are ambiguous, report timestamp coverage and mark data age unscored rather than inventing precision.

The weekend rule

Interbank FX closes for the weekend. A provider may legitimately carry its final trading-week value, but the benchmark records whether it labels that condition. A changing crypto-derived proxy, a carried FX observation, and a daily reference fix are different products; the report must preserve the provider’s source and market-state metadata instead of calling all three “live.”

The publication gate

Every published result must include the sample count, success count, p50 and p95 data age, p50 and p95 observed change interval, availability, timestamp coverage, source-label coverage, observation window, measurement region, plan, parser version, and exclusions. Raw normalized observations should accompany the summary wherever provider terms allow redistribution.

Machine-readable protocol

Download the versioned benchmark protocol. It defines eligibility, recorded fields, formulas, required disclosures, prohibited claims, and the current result status. The broader FX data methodology defines exchangerate.dev’s own source and timestamp semantics.