The Rithmic API Problem: Why There's No Public REST Endpoint — and How the WebSocket Protocol Actually Works

If you have ever tried to automate a futures account, you have met this wall: your broker runs on Rithmic, Rithmic is fast and everywhere, and there is no page anywhere that says here is your API key.

You will find forum threads from 2019 asking the same question. You will find a Python library on GitHub with a warning that it may stop working. You will find a PDF. What you will not find is a REST endpoint, a sandbox, or a signup flow — because they do not exist.

We spent a good part of this year inside that wall, building a service on top of it. This article is the map we wish we’d had: what Rithmic actually offers, how the WebSocket really works, and the specific traps that cost us the most time. Every technical claim below comes out of our own running code, including the mistakes.

What Rithmic is, and why this is confusing

Rithmic is infrastructure, not a retail product. Their software sits between exchanges and the platforms traders actually click in — and a large share of retail futures order flow rides on it, especially through prop firms.

That structure explains the confusion. You are not Rithmic’s customer. Your broker or prop firm is. So when you go looking for developer docs, you are looking for something aimed at a company integrating a platform, not at an individual who wants to place an order from a script. There is no self-serve tier because self-serve was never the model.

Rithmic offers two ways in.

R|API+ — the native SDK path

R|API+ is a set of native libraries: C++, C# (.NET) and Java. This is what most commercial platforms are built on, it is mature, and it is fast.

Three things make it painful outside a Windows desktop app:

1. It is a binary SDK, not a protocol you can implement. You link their library. Python, Go, Rust and JavaScript are out unless you build a bridge process — which is exactly what we ended up doing: a small .NET service whose only job is to translate.
2. The Linux story is awkward. Getting a login working outside Windows is possible but fiddly enough that we develop that component directly on the server it runs on, because reproducing the environment locally was not worth the effort.
3. It pins a deployment into the connection. This is the big one, and it deserves its own section.

The deployment trap that breaks prop-firm accounts

Rithmic does not run one system. It runs many separate deployments, and your account exists on exactly one of them.

With R|API+ you connect by supplying gateway addresses for that deployment. Fine when it’s your own retail broker and you can look the addresses up. Not fine for prop firms, which each sit on their own deployment whose addresses you generally do not have.

The failure mode is brutal because it isn’t a bug you can find in your code: your integration works perfectly against your retail demo account, then reaches a funded prop account and simply cannot connect. Nothing is wrong with your logic. You are dialling a system that doesn’t answer.

This is precisely why we built our trading sidecar on R|Protocol instead, where the deployment is selected by a system_name string. One service reaches all of them. If you take one practical thing from this article, take this: if prop-firm accounts are in scope, R|API+ is probably the wrong path.

R|Protocol — the WebSocket path

R|Protocol is the WebSocket interface, and for anything that isn’t a Windows desktop application it is the more practical of the two. It terminates at:

wss://rprotocol.rithmic.com:443/

That URL is where most people’s expectations break. A WebSocket URL suggests you can connect and read JSON. You cannot. R|Protocol speaks Protocol Buffers. Every frame is a binary protobuf message identified by a numeric template ID — one number for “login request”, another for “subscribe”, another for “order notification”. Without Rithmic’s .proto definitions you can neither encode a request nor decode a reply.

So “Rithmic has a WebSocket API” is true, and “you can talk to it this afternoon” is not.

Plants: four logins, not one

The single most important structural fact: Rithmic is split into plants, and you log into each one separately, over its own connection.

Plant	What it gives you
TICKER	Live market data — trades, quotes, order book
HISTORY	Historical bars and ticks
ORDER	Order entry, order state, trade routes
PNL	Positions, net quantity, account metrics

You want live prices and your position? Two plants, two logins. Orders and account balance? Two plants.

And here is the trap: the plants coexist, but they share one user identity. Log into a plant a second time with the same credentials and the first session can be forcibly logged out. Our own backfill tool carries a warning in its header for exactly this reason — it uses the HISTORY plant while the live service holds TICKER, and we learned to never run two of them at once. If you see mysterious disconnects that correlate with your own deploys, this is usually why.

Two things the WebSocket quietly won’t tell you

The history plant has no depth request. You can replay trades and bars, but there is no order-book history. If you want L2 or L3 history you have to record it yourself, from the day you start. There is no way to get yesterday’s book.

Replays cap silently at 10,000 bars. Request a busy window of tick bars and the response comes back looking neatly complete — with exactly 10,000 rows. No flag, no error, no truncation warning. We caught this by comparing a ten-minute window against our own recording: the vendor returned 10,000 where we had 11,079. If you are building a backfill, you must chunk small enough to stay under the cap and verify counts, or you will silently ship gaps.

The order-routing landmine

This one is worth the price of the whole article if you are writing order code.

When you place an order you must specify a trade route — the path from Rithmic to the exchange. Accounts have different routes, and the correct one is discoverable at runtime.

The open-source Rust client we build on hardcodes it: "simulator" for demo, "globex" for live, and it ignores the route discovery call entirely. If your account’s real route happens to be neither, every order you send is rejected at the exchange, with no local error to catch. Your code looks fine. Your logs look fine. Nothing fills.

Our sidecar therefore discovers the route on connect, picks the environment whose constant actually matches it, and — if neither matches — refuses to place orders while still serving positions and fills read-only. Degrading to read-only beats pretending to trade.

A second, smaller version of the same lesson: when Rithmic rejects an order, it frequently leaves the status field empty and puts the outcome in report_type. Read the wrong field and a rejected order looks like a pending one forever.

Two operational lessons that cost us real pain

Do not reconnect too fast. After a crash, Rithmic holds the market-data seat for roughly 60–90 seconds. Log back in before it clears and you get rejected, and if your supervisor restarts you in a tight loop, you have built a crash loop that cannot recover on its own. Our restart delay exists because we lived this.

Do not storm the login. In July we triggered an IP ban with a burst of login attempts during development. Not a rate-limit response — a block, at the network level, that took the whole feed down until it was sorted out. If you are testing credentials, throttle yourself hard and treat login as an expensive operation. This is the single most consequential mistake we made all year, and it was entirely self-inflicted.

Positions come from the broker, never from your own arithmetic. It is tempting to track your position by counting your own fills. Don’t. The PNL plant reports net_quantity per instrument, which means a manual trade you placed in your platform, or a flatten by the prop firm’s risk system, is visible. Count your own fills instead and your state silently desynchronises from reality the first time anything happens outside your code.

So what are your actual options?

Use a platform and give up automation. Fine for discretionary trading, useless if you want a script in the loop.

Get R|API+ access and build the bridge. Legitimate, and the right answer if you are building a platform. Budget for the conformance process, a bridge process for your language, and the deployment problem if prop accounts are in scope.

Implement R|Protocol yourself. Doable — protobuf over WebSocket, four plants, heartbeats, reconnect logic, route discovery, and the traps above. Realistically weeks of work before your first reliable fill, most of it spent on things that have nothing to do with your strategy.

Let someone else hold that complexity. Which is the part where we tell you what we built, and exactly where its edges are.

What tickstream gives you today

We did the integration work, and one piece of it is live for customers right now: your Rithmic account state and trade history over plain HTTP, with one bearer token.

You link your own Rithmic account once in the dashboard — your credentials route only your own account and are never shared. After that:

curl https://api.tick-stream.xyz/v1/exec/positions \
  -H "Authorization: Bearer sk_live_…"

curl "https://api.tick-stream.xyz/v1/exec/fills?symbol=NQU6&start=1751000000" \
  -H "Authorization: Bearer sk_live_…"

You get net quantity per symbol, average open price, open and closed PnL, account balances, and every fill as JSON — filterable by account, symbol and time range. No SDK, no protobuf, no plant juggling, no deployment addresses, no route discovery. A session is maintained for each linked account automatically, and snapshots refresh about once a minute.

That last endpoint is quietly the most useful one. Your fill history as raw data means you can compute your own win rates, per-symbol PnL and time-of-day breakdowns — or measure your real slippage against our tick history, which is the same feed our own published research runs on.

The write side: working, but not yet yours

Order placement is not vapourware here, and it would be false modesty to describe it as unfinished. It runs in production every session — just not as an endpoint you can call yet.

What is live on our side, right now, is the thing this whole article says is hard:

• Prop-firm accounts connected over R|Protocol, selected by system_name, with no R|API deployment addresses anywhere — the exact wall described above, on the other side of it. Our engine’s own log line for a linked Apex account reads transport: R|Protocol (system "Apex", no R|API deployment).
• Trade route discovered at connect, with the account refusing to trade — while still serving positions and fills — when the discovered route doesn’t match a route we can actually send on. No silent exchange rejects.
• Protective orders resting at the broker. Stop and target are native OCO legs held by Rithmic, not timers in our process. We proved a stop resting and triggering on a real MNQ position rather than assuming it.
• Position truth from the PNL plant, so a manual trade or an outside flatten by the firm’s risk system is visible instead of quietly desynchronising us.
• Automatic session-close flattening — every account flat before the close, no new entries until the next session opens.
• A kill switch that flattens and disarms everything from one config flag.

That is what our algo sleeves trade through, on simulated prop-evaluation accounts, and their records are public.

So why is there no POST /v1/exec/order for you? Because the distance between our engine trading our accounts and a public endpoint trading yours is not a routing problem — it is a multi-tenancy, credential-custody and blast-radius problem. One bug in a shared order path can lose someone else’s money in a way no refund fixes. It opens demo-first, per-user isolated, with the kill switch, when it has earned it — not because an article needed a stronger closing line.

So the accurate version of our pitch, today: we make the read side of Rithmic trivial, and the write side is proven but still ours. If the read side is what you need — account state, positions, a complete fill history as data — that is one HTTP call away and costs a few dollars a month. If you need to place orders from a script today, R|Protocol and the traps in this article are your road, and we hope the map saves you the weeks it cost us. When the write side opens, the hard parts above will already be behind it.

The Account API is documented at /docs/execution. The market-data side — live futures ticks, Level 2 and Level 3, options chains and years of history — is documented here and priced here.