Real-Time Forex Rates API vs Free Delayed Feeds: How to Choose

Two screens, one currency pair, two different numbers. A finance lead sees EUR/USD at 1.0847 on an internal dashboard while a treasury counterpart quotes 1.0851, and the next twenty minutes vanish into working out which one is broken. Usually neither is: one number came from a feed that refreshes on a fifteen-minute timer, the other from a live quote stream.

That gap is the entire decision behind choosing a real time forex rates API over a free delayed feed. Free endpoints are genuinely useful, and plenty of production systems run on them happily for years. The skill is knowing which side of the line a workload sits on before it ships, rather than after a customer opens a ticket.

Key takeaways

• "Real-time" means tick-level updates with separate bid and ask prices — not a single number refreshed on a timer.
• Trading dashboards, dealing screens and price alerts degrade badly below sub-second freshness; invoicing, accounting and reporting rarely do.
• Free feeds typically publish one mid price on a slow cadence, with tight call limits and no uptime commitment.
• Match freshness to the decision the number drives: money moving now needs live quotes, money recorded later needs a stable daily fix.
• A hybrid setup — live stream for the UI, stored daily fix for the ledger — is usually cheaper and more defensible than picking one.

What "real-time" concretely means

Ticks, not refreshes

Foreign exchange has no central exchange. Prices change when a liquidity provider changes a quote, and each of those changes is a tick. During the London–New York overlap, major pairs such as EUR/USD can tick several times per second; in thin overnight hours, a minor pair may sit still for minutes.

A real-time API surfaces those changes as they happen. A delayed feed samples — it keeps one quote per interval and throws away everything in between. That distinction matters more than the headline latency number, because sampling silently destroys information: an intraday spike that lasted forty seconds simply never existed as far as a fifteen-minute feed is concerned. Any alert, stop-loss check or high/low calculation built on sampled data inherits that blind spot.

Bid, ask, and the spread

The second half of "real-time" is that a proper feed carries two prices. The bid is where the market will buy from a seller; the ask is where it will sell to a buyer. The difference is the spread, and it is the actual cost of transacting.

Most free feeds publish only a mid price — the midpoint of bid and ask — which is a number nobody can trade at. For invoicing that is arguably the fairest choice. For anything that shows a customer a price they will act on, mid understates cost, and the error always leans the same way. Spreads also widen around economic releases and the daily rollover; a mid-only feed hides that entirely, so a system looks calmest exactly when conditions are worst.

curl "https://www.live-rates.com/api/rates?key=YOUR_API_KEY"

An illustrative response for a single pair:

[
  {
    "pair": "EURUSD",
    "rate": 1.08472,
    "bid": 1.08465,
    "ask": 1.08479,
    "high": 1.08731,
    "low": 1.08302,
    "open": 1.08610,
    "timestamp": 1754812800
  }
]

The spread here is 0.00014, or 1.4 pips. A mid-only feed would report 1.08472 and drop both sides of it. Note the timestamp as well: any feed worth integrating states when the quote was formed, so staleness is measurable instead of assumed. If an endpoint returns a price with no timestamp, treat its freshness as unknown.

What free delayed feeds are genuinely good at

Central bank reference rates — the ECB publishes its daily euro fix each business day in the afternoon, Central European time — and the free tiers of commercial APIs are excellent for a specific class of work: daily-granularity charting, accounting entries, contract terms, tax reporting, and dashboards where the rate is context rather than a trigger.

They have one property a live stream cannot offer: reproducibility. A published daily fix is a single citable number that every system agrees on. A live tick is not reproducible by design — two services calling the API 300 ms apart will legitimately disagree, and both will be right. For anything an auditor or a customer dispute will revisit, that stability is a feature, not a limitation.

Where free feeds break down is rarely accuracy and almost always operations: low call ceilings, a single fixed base currency that forces client-side cross-rate maths, mid prices only, no service commitment, and breaking changes shipped without notice.

Decision table: freshness by use case

A shortcut for reading the table: ask what someone does with the number within a minute of seeing it. If the answer is an irreversible, money-bearing action, buy freshness. If the answer is "files it," buy stability instead.

Comparing the two feed types

What to check before committing

Cadence versus polling interval

Polling a source ten times a second that only updates once a second buys nothing but rate-limit pressure. Confirm the underlying update frequency, then set the polling interval to match it. Also check how limits are expressed — a per-five-minute window behaves very differently from a monthly quota when traffic is bursty.

Coverage and how crosses are built

Some providers quote a few dozen pairs directly and synthesise the rest through USD. Synthetic crosses are fine for reporting and less fine for anything spread-sensitive, because two spreads get compounded. Reviewing the full list of live rates against the pairs actually needed is a five-minute check that prevents a late surprise.

Failure behaviour

Decide in advance what the application shows when the feed is unreachable. Serving a last-known price with a visible timestamp is almost always better than a blank field, and far better than serving a stale price as though it were current.

The hybrid pattern that usually wins

Most teams do not have to choose. The durable architecture uses a real-time feed for anything a user watches or acts on, and a stored daily fix for anything that lands in the ledger. Critically, whenever a transaction is booked, the rate, its timestamp and its source are persisted alongside it. That single habit ends the majority of "which number is right" arguments, because the answer stops being a live lookup and becomes a recorded fact.

FAQ

What does "real-time" actually mean for a forex API?

It means the API reflects individual quote changes, or ticks, as liquidity providers publish them, and exposes bid and ask separately rather than a single averaged price. On major pairs during active sessions that can be several updates per second.

Is a free delayed feed accurate enough for invoicing?

Usually yes. Invoicing needs a rate that is stable, citable and identical across systems, which is exactly what a published daily fix provides. Delay is not an error when the number is being recorded rather than traded on.

Should an application use bid, ask, or mid?

Use the ask when a customer is buying the quote currency and the bid when they are selling, so the spread is accounted for honestly. Mid is appropriate for reporting, valuation and display where no transaction is being priced.

How often should a real-time rates API be polled?

Match the polling interval to the source's update cadence and the workload: roughly once per second for live dashboards and alerts, every one to five minutes for revaluation, and once daily for accounting. Cache aggressively so a busy front end maps to a modest number of upstream calls.

The honest test is which side of the freshness line each workload sits on — and most products have workloads on both. Compare the pair coverage and update cadence against that decision table, then pick a tier on the Live-Rates plans page that fits the polling pattern the application actually needs.