"What is 100 euros in dollars right now?" and "chart EUR/USD bid/ask for the last six months" feel like the same question. They are not, and the gap between them is the single most expensive decision a fintech MVP makes before writing any code. Both get called a "forex API." One is a currency conversion API that hands back a single mid rate refreshed every minute or so. The other is a forex market data API that delivers live bid/ask quotes and historical OHLCV bars. Pick the wrong one and you either rebuild your data layer halfway through, or you pay for tick infrastructure an e-commerce checkout never touches.
This post maps each need to a concrete endpoint so you can decide on day one.
Currency conversion API vs forex market data API: the core difference#
A currency conversion API answers a transactional question: given an amount in currency A, what is the equivalent in currency B at a reference rate. The output is one number. It does not carry a spread, it does not tell you the size resting on either side of the market, and it usually refreshes on a slow cadence (every 60 seconds is common, sometimes hourly). That cadence is a feature, not a limitation. A checkout that re-prices on every tick would show a different total each time the user blinks.
A forex market data API answers a market question: where is EUR/USD trading, how has it moved, and what does the order book look like right now. The output is structured: a bid, an ask, timestamps, and a stream or history of bars. You use it to draw charts, compute volatility, drive alerts, and backtest. It changes many times per second.
The practical test is one question. Are you settling a transaction, or are you observing a market? Settlement wants a stable, slow, single rate. Observation wants depth, freshness, and history.
When a conversion feed is the right call#
If you are building an e-commerce checkout, a multi-currency invoice, a travel-expense tool, or a treasury dashboard that reports balances in a home currency, you want a mid rate, not tick data. The mid is the midpoint between bid and ask, and for display-and-settle purposes it is the honest single number.
With SiftingIO you do not need a separate conversion product for this. The live quote snapshot already carries everything a conversion needs, and you derive the mid yourself:
curl -H "X-API-Key: $SIFTING_KEY" \
"https://api.sifting.io/v1/last/quote/forex/EURUSD"
The response gives you the best bid b and best ask a. The conversion rate is (b + a) / 2. Cache it for 60 seconds, multiply against the amount, and you have a stable checkout price that will not flicker between page loads. One credential, one endpoint, and you control the refresh cadence instead of inheriting someone else's.
The value of pulling that mid from a market data provider rather than a single bank feed is consensus. SiftingIO publishes one fair price per pair, aggregated as a reputation-weighted robust median across multiple independent venues, so a single venue printing a stale or off-market EUR/USD does not drag your checkout total with it. For a conversion that touches real money, a cross-venue reference is frequently more correct than any one source.
When you need a forex market data API#
The moment your product shows a chart, computes a moving average, fires an alert on a level break, or runs a backtest, a once-a-minute mid rate is not enough. You need two things a conversion endpoint will never give you: the live bid/ask spread and historical bars.
For live observation, the same quote endpoint gives you both sides of the market, and the spread a - b is itself a signal (it widens in thin conditions). For anything streaming, open the WebSocket instead of polling:
wss://stream.sifting.io/ws/v1?key=$SIFTING_KEY
then send {"op":"subscribe","product":"fx","symbols":["EURUSD","USDJPY"]} and read tick frames as they arrive. On subscribe the server first emits the last cached value, then live updates, so your chart paints immediately instead of waiting for the next move.
For history, pull OHLCV bars. Heavy historical endpoints require gzip, so set the header:
curl -H "X-API-Key: $SIFTING_KEY" \
-H "Accept-Encoding: gzip" \
"https://api.sifting.io/v1/hist/forex/EURUSD/bars?interval=1h"
You get open, high, low, close per interval, from 1m up to 1h for FX, timestamped in UTC. That is the input a backtest, a volatility model, or a candlestick chart actually consumes. A conversion API has none of it.
The schema is the same as a stock bar#
Here is the part that saves you a rewrite later. A forex bar from /v1/hist/forex/EURUSD/bars has the same shape as a US equity bar from /v1/hist/stocks/AAPL/bars: open, high, low, close, volume, timestamp. The normalized schema is identical across asset classes, so the function that renders a EUR/USD chart renders an AAPL chart with no changes, and the same parser handles BTCUSD crypto bars too.
That matters for an MVP because scope creep in fintech almost always means adding an asset class. You start with FX, then someone asks for a gold line (XAUUSD) and a crypto tile (BTCUSD). If your bars share one schema behind one API key, that is a new symbol string, not a new integration, a new vendor, and a new auth scheme. Build the chart component once against the bar shape and reuse it everywhere.
One caveat to bake in early: for FX bars the volume field v is always 0. There is no consolidated forex tape, so do not build a feature that depends on FX volume. Crypto bars do carry real base-asset volume in v, and equity bars carry share volume, so the field is meaningful for those classes.
Common pitfalls#
Three mistakes show up again and again when teams scope this wrong.
The first is building a trading dashboard on a 60-second conversion feed. The chart looks fine in a demo and then lags badly the moment a user watches a real move, because the underlying rate only updated once a minute. If the product observes a market, start with the quote and bars endpoints, not a conversion rate.
The second is over-engineering a checkout on tick data. Subscribing a WebSocket so an invoice can show a price the customer never asked to watch live burns connections and subscription slots against your plan limits for no benefit. Poll the quote endpoint, take the mid, cache it.
The third is forgetting gzip on historical bars. The hist and financials endpoints require it and return 406 gzip_required without the Accept-Encoding: gzip header. A 406 here is not a permissions problem, it is a missing header, so check that before you go hunting through your API key entitlements.
Decide which question your product asks (settle a transaction or observe a market) before the first line of code, and the endpoint picks itself.
