DEV Community: Alper San

Market data over FIX 4.4 for high-performance trading systems

Alper San — Thu, 25 Jun 2026 19:42:06 +0000

Pull cross-venue reference prices over a FIX 4.4 market-data session for crypto, forex, and metals, then feed them into
MetaTrader. Market data only.

Your trading system already speaks FIX. The strategy engine, order manager, and risk checks all parse tag=value messages over a persistent session, and bolting on a separate transport just for reference prices means another reconnect loop, another schema, and another thing to page someone about at 3 am. So the question is narrow and practical: how do you pull clean crypto, forex, and metals prices into a pipeline that already talks FIX, without standing a REST poller next to it?

SiftingIO exposes its aggregated market data over a FIX 4.4 session. One detail matters before anything else, because it shapes every design decision downstream: this is a market-data path, not an order-entry one. There is no order routing, no execution, no liquidity bridge. What comes down the wire is the same cross-venue consensus price the REST and WebSocket APIs serve, formatted as standard FIX market-data messages. The useful framing for a low-latency desk is a reference of record that sits above the execution feeds you already have, so you can sanity-check the quote a venue is printing against an independent consensus value.

The session lifecycle

The transport is TCP over TLS from IP-allowlisted source addresses, terminating at one of three cross-connect points: TY3 in Tokyo, NY4 in New York, and LD4 in London. Pick the one closest to where your engine runs. FIX 4.4 is the standard dialect, with FIX 5.0 SP2 available on request.

A session opens with a Logon (35=A) carrying your SenderCompID and the TargetCompID of SIFTINGIO. After that, the connection is kept alive with a Heartbeat (35=0) on a 30-second interval, and a TestRequest (35=1) prompts a heartbeat if the counterparty has gone quiet. Logout (35=5) closes it cleanly.

Subscribing is a MarketDataRequest (35=V). You set SubscriptionRequestType to a snapshot-plus-updates subscription, list your symbols using SiftingIO canonical codes, and the server answers with a MarketDataSnapshotFullRefresh (35=W) to seed the book, then a stream of MarketDataIncrementalRefresh (35=X) messages for every change after that. If you ask for something you cannot have, you get a MarketDataRequestReject (35=Y) instead. To discover what you can subscribe to, a SecurityList request (35=x) returns the tradable universe (35=y).

The price entries themselves ride in repeating groups keyed by MDEntryType (269): bid is 0, offer is 1, and trade is 2. Each entry carries MDEntryPx (270) for the price and MDEntrySize (271) for the size, with NoMDEntries (268) up to three per update. A minimal subscribe message for a crypto pair looks like this in pipe-delimited form:

8=FIX.4.4|35=V|49=YOUR_SENDER|56=SIFTINGIO|
262=req-btc-1|263=1|264=1|267=2|269=0|269=1|
146=1|55=BTCUSD|

That asks for bids and offers on BTCUSD as a live subscription. Symbols follow the canonical pair form you already use elsewhere on the platform: BTCUSD and ETHUSD for crypto, GBPUSD for forex, XAUUSD for metals.

Using it as a validation layer

The stronger use of an independent feed is not to drive execution from it, it is to catch the moment your execution venue is wrong. For fragmented and thin markets there often is no single true price, so a consensus median across multiple independent venues is frequently more correct than any one venue's print. The FIX session gives your low-latency path that consensus value, and a comparison against what your broker is quoting flags a stale, thin, or manipulated number before it reaches a risk decision.

The same consensus price is reachable over REST, which is handy for a backfill job or a slower out-of-band check that does not justify a FIX session of its own:

curl -H "X-API-Key: $SIFTING_KEY" \
  "https://api.sifting.io/v1/last/quote/crypto/BTCUSD"

That returns the latest best bid and ask snapshot. REST auth is the X-API-Key header; the FIX side authenticates through your CompID pair and the IP allowlist instead. There is no Bearer token anywhere.

Wiring the feed into MetaTrader

A common destination for this feed is a MetaTrader 4 or 5 server that needs prices for Market Watch, charts, and indicators. SiftingIO supports that as a server-side market-data path, again with no execution or liquidity component. Your bridge runs a FIX initiator (QuickFIX or a compatible engine), allowlisted by IP, that maps SiftingIO canonical codes to your platform symbols and pushes bid and ask into the MT4 DataFeed API or the MT5 Gateway API, which then broadcasts to every client terminal. The full setup, including the BeginString=FIX.4.4 and TargetCompID=SIFTINGIO session config, is documented on the MetaTrader integration page.

Common pitfalls

Forex and metals carry no trade entries. Only crypto publishes MDEntryType 2; for GBPUSD or XAUUSD you will only ever see bid (0) and offer (1). A handler written against crypto that waits for a trade print to compute a price will sit silent forever on those symbols. Derive a mid from the bid and ask instead.

Do not expect a ResendRequest to replay missed ticks. For market data the server answers a gap with a SequenceReset-GapFill rather than re-sending stale prices, which is the correct behavior: a quote from two seconds ago is noise, not recovery. After a gap, resynchronize from the next MarketDataSnapshotFullRefresh rather than trying to reconstruct what you missed.

Watch the source IP. The allowlist is matched on the connecting address, so a session behind NAT, a load balancer, or an ephemeral cloud egress IP will fail Logon with no useful application-level message. Pin static source IPs and confirm them before debugging anything higher in the stack. Separately, a MarketDataRequestReject (35=Y) on a symbol you believe is valid is usually an entitlement limit, not a bad symbol: concurrent sessions and symbols-per-session are capped by plan, and FIX access itself sits behind a FIX entitlement.

One last framing note that keeps you on the right side of the data: the value on the wire is a synthetic reference price, not an official exchange-of-record print and not executable depth. It is built to be resistant to a minority of bad feeds, not to survive a majority of venues all erring the same way, and it is a reference rather than a sub-millisecond execution feed. Treat it as the cross-check above your trading stack, and it earns its place in a fast pipeline.

Read the docs

Building a cleaner symbol catalog for market data APIs

Alper San — Tue, 16 Jun 2026 18:37:08 +0000

Building a cleaner symbol catalog for market data APIs

Market data integrations usually become messy for one simple reason: symbols are not always treated as product-level objects.

A stock symbol, a forex pair, a crypto pair, and a commodity contract may all look similar in a UI, but they often behave differently in an API integration. They may come from different data pipelines, support different endpoints, return different fields, or require different handling across REST and WebSocket connections.

We recently added a public symbol catalog to SiftingIO to make this layer more transparent.

The catalog covers supported symbols across US stocks, forex, crypto, and commodities. Each indexed symbol page is designed to show how that symbol can be used inside SiftingIO’s market data APIs, including REST examples, WebSocket usage, available fields, and related symbols.

The goal is not to publish a large static list.

The goal is to make each supported symbol easier to understand as an API object.

For example, a symbol page should help answer practical integration questions such as:

Which asset class does this symbol belong to?
What symbol key should be used in API requests?
Can it be used with REST endpoints?
Can it be used with WebSocket streams?
What fields are returned for this symbol?
Which related symbols may be useful in the same workflow?

This becomes important when building trading platforms, market dashboards, portfolio tools, financial apps, internal analytics systems, or backtesting workflows. The symbol format should not be something developers need to reverse-engineer from scattered examples.

We also kept the SEO footprint intentionally curated. Not every available symbol needs an indexed page. Thin, duplicated, long-tail pages are not useful for developers and they are not useful for search engines. For the first version, we are indexing a focused set of high-demand symbols and keeping the rest accessible through search.

You can explore the catalog here:

https://sifting.io/symbols

We will continue improving the catalog with better metadata, richer examples, and more asset-class-specific context over time.

How to Get Real-Time Forex Prices with REST and WebSocket

Alper San — Thu, 28 May 2026 15:43:54 +0000

Real-time forex data is one of the most common requirements in financial applications.

You might need it for:

A live EURUSD ticker
A currency converter
A pricing screen
A trading dashboard
A price alert system
A research or backtesting workflow

In most cases, there are two practical ways to read live FX prices:

Use a REST API when you need the latest quote at a specific moment.
Use a WebSocket stream when your application needs continuous updates.

This guide shows how that works with SiftingIO.

Originally published on the SiftingIO blog:
https://sifting.io/blog/how-to-get-real-time-forex-prices-from-siftingio

What real-time forex data means

Real-time forex data usually includes the latest quote for a currency pair.

For a pair like EURUSD, the most important fields are:

Bid: the price buyers are offering
Ask: the price sellers are asking
Mid: the midpoint between bid and ask
Spread: the difference between bid and ask

A real-time forex feed keeps those values updated as the market moves.

With SiftingIO, you can read forex prices through REST snapshots or WebSocket streams using the same API key and the same general data model.

Option 1: Get the latest forex quote with REST

If your application only needs the current price occasionally, a REST request is usually enough.

Example:

curl -H "X-API-Key: $SIFTING_KEY" \
  "https://api.sifting.io/v1/last/quote/forex/EURUSD"

This returns the latest quote snapshot for EURUSD.

A REST snapshot is useful for:

Currency converters
Dashboards that refresh every few seconds
Scheduled price checks
Backend jobs
Recovery after a WebSocket reconnect

The important point is that you do not need to maintain a live connection just to read the latest available quote.

Option 2: Stream live forex prices with WebSocket

If your screen or system needs continuous price updates, polling the REST API every second is usually not the best approach.

In that case, use a WebSocket stream.

Example:

const ws = new WebSocket(`wss://stream.sifting.io/ws/v1?key=${process.env.SIFTING_KEY}`);

ws.onopen = () => {
  ws.send(JSON.stringify({
    op: "subscribe",
    product: "fx",
    symbols: ["EURUSD", "GBPUSD", "USDJPY"],
  }));
};

ws.onmessage = (event) => {
  const update = JSON.parse(event.data);

  if (update.f === "tick") {
    console.log(update.s, "bid", update.b, "ask", update.a);
  }
};

With WebSocket, you subscribe once and receive updates as prices change.

This is better for:

Live tickers
Trading screens
Monitoring tools
Alerts that need fast reaction
Applications watching multiple currency pairs at once

REST vs WebSocket for forex prices

Use REST when:

You only need the latest quote now
You are building a simple converter
You refresh a dashboard on a schedule
You want a clean request-response workflow

Use WebSocket when:

You need prices to update continuously
You are watching several pairs at the same time
You want to avoid constant polling
A delay of even a few seconds matters to the user experience

Both approaches are valid. The right choice depends on how your application uses the data.

Weekend and market-hours behavior

The forex market does not produce new prices all weekend.

A good application should not treat that as a broken feed. It should show a clear market-closed or stale-data state when appropriate.

For example:

Keep timestamps in UTC internally
Convert to local time only when showing users
Handle weekends and market gaps explicitly
Show the last available quote clearly when the market is closed

This is especially important for dashboards, converters, and alert systems that users may open outside normal FX market hours.

Common use cases

Real-time forex data is commonly used in:

Currency converters
Treasury dashboards
Trading tools
Pricing screens
FX alerts
Research platforms
Internal finance systems
Backtesting workflows

The same application may use both REST and WebSocket.

For example, a dashboard might load the latest quote with REST when the page opens, then switch to WebSocket for live updates.

Getting started

SiftingIO provides real-time and historical market data APIs for stocks, FX, crypto, commodities, DEX, and on-chain markets through REST and WebSocket.

For forex prices, the workflow is simple:

Create an API key
Request the latest quote with REST
Use WebSocket when you need continuous updates
Keep your integration consistent across supported asset classes

Useful links:

Forex Market Data API: https://sifting.io/product/forex
Documentation: https://sifting.io/docs
Postman Collection: https://www.postman.com/siftingio/siftingio-market-data-api
Original article: https://sifting.io/blog/how-to-get-real-time-forex-prices-from-siftingio

One Bridge for every OpenAI route

Alper San — Sat, 02 May 2026 10:58:08 +0000

One SaltingIO Bridge can stand in for every OpenAI route you call. Here's how template variables turn five endpoints into a single, parameterised proxy.

Last month I was hooking SaltingIO up to a small chat UI that needed three OpenAI calls: chat completions, embeddings, and a moderation check before sending anything user-typed upstream. My first instinct was the obvious one. Three separate Bridges, three UUIDs, three fetches from the frontend.

It worked. It was also annoying.

Every time the team wanted a new OpenAI feature (assistants, vector stores, an admin call to list models), I was back in the dashboard creating another Bridge, copying another UUID into the codebase, redeploying. The credential never changed. Only the path did. That's not the shape of a problem that should require N records.

If you've felt the same itch, this post is about how template variables in a Bridge URL collapse those N records into one. I'll walk through the working setup, the curl shape, the trade-offs, and the one thing that bit me on the way.

The shape of a templated Bridge

A SaltingIO Bridge stores a destination URL plus headers, methods, and origin rules. The destination URL is the part most people leave static, but it accepts a templating syntax: {{name}} placeholders that get substituted at request time from query parameters.

So instead of pinning the Bridge to

https://api.openai.com/v1/chat/completions

, you point it at:

https://api.openai.com/v1/{{path}}

The Authorization header still carries your sk-... key, stored once on the Bridge. Allowed methods are POST and GET. Allowed origins are your two or three frontends.

From the browser:

const res = await fetch(
  `https://api.salting.io/r/${BRIDGE_UUID}?path=chat/completions`,
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      model: "gpt-4o-mini",
      messages: [{ role: "user", content: "say hi" }],
    }),
  },
);

Same UUID, different path, totally different OpenAI route. The body is forwarded as-is. Your key never touches the browser.

Curl, in case you want to sanity-check from a terminal:

curl -X POST \
  "https://api.salting.io/r/$BRIDGE_UUID?path=embeddings" \
  -H 'Content-Type: application/json' \
  -d '{"model":"text-embedding-3-small","input":"hello"}'

The placeholder is case-sensitive. {{path}} and ?path= line up. {{Path}} against ?path= will silently miss and the upstream call goes to /v1/{{Path}}, which is not a fun stack trace to read on a Friday afternoon.

Why one Bridge beats N Bridges

There's a maintenance argument and a security argument.

The maintenance side is small but real. One Bridge means one origin allowlist to keep in sync, one set of allowed headers, one place to rotate the OpenAI key when it inevitably leaks (everyone leaks one eventually). When you have five Bridges all pointing at OpenAI with the same key, rotating that key is five edits, and the chance you forget one scales linearly.

The security argument is more interesting. The fewer records in your account, the smaller your attack surface in the dashboard itself. If a Viewer on your team account gets a stale browser session, you'd rather they could enumerate one record than seven. SaltingIO Logs aggregate per-UUID, so a single Bridge also collapses your usage view into one row. You see total OpenAI spend per day on one chart instead of summing five.

The flip side: a templated Bridge is more permissive than a fixed one. The whole /v1/{{path}} family is now reachable from your frontend, including routes you didn't intend to expose. If the only thing you ever call is chat/completions, a static Bridge to chat/completions is a tighter fit. Templating widens the door so you don't have to keep cutting new ones.

Constraining the template

You can pull the door back in two ways.

First, allowed methods. If your real traffic is only POST, drop GET, PUT, PATCH, DELETE from the Bridge config. A leaked UUID with a method allowlist of just POST cannot, for example, drive DELETE /v1/files/{file_id} even with the right path value.

Second, validate on your side. Template variables are substitution, not validation. If you want to accept only chat/completions, embeddings, and moderations, do that check in your client code before the call goes out. SaltingIO won't reject path=admin/something-you-shouldn't-touch. It'll happily forward it.

For most apps, methods plus the origin allowlist are enough, and the wins from one Bridge per upstream are worth the wider path surface. But if you're handing a Bridge to a less-trusted internal team, lean toward a static URL. The point of {{path}} is consolidation for routes you already trust yourself to call.

Combining with response transformation

The other thing that pairs well with template variables is ?select=. SaltingIO can reshape the upstream JSON before it reaches the browser using a GJSON path.

OpenAI chat responses are chunky. The piece you usually want is choices.0.message.content. Adding &select=choices.0.message.content to the same Bridge call returns just that string, wrapped in the standard { "data": "..." } envelope:

curl -X POST \
  "https://api.salting.io/r/$BRIDGE_UUID?path=chat/completions&select=choices.0.message.content" \
  -H 'Content-Type: application/json' \
  -d '{"model":"gpt-4o-mini","messages":[{"role":"user","content":"hi"}]}'

Two query params, one Bridge, no backend, no exposed key, no 4 KB of JSON the user agent has to parse just to grab a string. It's the kind of small win that adds up across a session.

Where this approach is the wrong tool

Templating is not a fit for every Bridge. A few honest caveats.

If your upstream is on multiple hostnames (you're calling both api.openai.com and api.anthropic.com from the same UI), one Bridge can't host both. The destination URL field is one host. Two upstreams means two Bridges. Don't try to template the host part to dodge that, it's a footgun.

If you need failover URLs (a primary plus backups tried in order), make sure the same {{placeholder}} shape exists in every entry. SaltingIO substitutes the same query parameters into the failover URL on retry, so a mismatch between primary and backup paths will silently send the failover request to a different route.

If you care about fine-grained per-route quotas, a single templated Bridge can't tell /embeddings traffic from /chat/completions traffic at the rate-limit layer. The Bridge sees one record, one budget. Split the routes if you need to budget them separately.

What I'd do tomorrow

If you're already on SaltingIO with two or three Bridges that share an upstream and a credential, try the consolidation. Create one templated Bridge, switch one frontend route over to it, watch Logs for a day, then migrate the rest. The rollback is one query param away.

If you haven't shipped your first Bridge yet, start with a templated one for whichever upstream you'll call most. Static is always a refactor away if you decide later you want a tighter fit.

Read the docs for the full template variable syntax, including header and body interpolation.