Pix APIs put the same tick-by-tick archive that drives our charting products directly into your code — alongside announcements, corporate data, news and option Greeks, live and historical. No client to install, no screen-scraping, no reconciling two vendors' idea of yesterday's close. Build the terminal, the scanner, the backtester or the risk sheet you actually wanted.
symbolContract or continuous series — TCSJUL19 and TCS_I both resolve
string
timestampSecond resolution, always IST, never re-stamped on replay
datetime
last priceThe traded price, as printed
decimal
volumeTraded quantity — aggregated from constituents on an index
integer
open interestAdjusted alongside price, not left raw across a roll
integer
open, high, low, closeOn bar requests, at tick, one-minute and end-of-day resolution
decimal
bid & askLevel 1, where the request carries quote depth
decimal
Same archive, same rules. Corporate actions applied across every resolution, no reprints after the close, and gaps backfilled rather than left.
The catalogue
Seven services, one set of credentials
Prices are the starting point, not the whole picture. A position is affected by an announcement, a result, a corporate action and the news around it — and on the options side, by Greeks that move faster than the price does. Each of these is a separate service; one registration covers whichever you need.
Realtime & historical
Market Data API
The core service. Every trade as it prints, with traded volume and open interest beside the price, plus the historical archive behind it — over REST for history and WebSocket for live.
Tick-by-tick realtime, with volume and open interest
Historical tick, one-minute and adjusted end-of-day series
Corporate actions applied across every resolution
Python, Node.js and .NET SDKs, or plain HTTP and JSON
Contract and continuous series both resolve, so you choose which you test on
Index volume aggregated from constituents, where an index has none of its own
Company filings and exchange announcements delivered as they are published, rather than found later. The reason a stock moved is often an announcement that landed two minutes earlier.
Announcements streamed as they hit the exchange
Attributable to the instrument, so it can drive an alert
Useful for surveillance dashboards and news-aware strategies
Results, fundamentals and corporate actions in one service. The context a price series cannot supply on its own — and the data a backtest needs if it is going to survive contact with a split.
A live market news feed for the screen that already has the chart on it. Built for products that need headlines beside prices rather than in a second browser tab.
Market news delivered live, ready to render in your own product
Pairs naturally with the announcement feed for a full picture
Option Greeks and implied volatility computed live, for products that need to see risk change rather than price change. This is the service behind our own gamma exposure tooling.
Delta, gamma, theta, vega and rho, live across the chain
Implied volatility alongside them
Batched requests, so a whole chain is one call rather than hundreds
Drives exposure maps, risk dashboards and options analytics
Stored Greeks and implied volatility, so a study reads what the screen actually showed at the time instead of a reconstruction from closing prices. Documented and ready to call.
Greeks held as history rather than recomputed on request
Mutual fund data for platforms that need it alongside equities and derivatives. Provisioned case by case rather than self-serve, so tell us what your product needs and we will scope it.
For distribution platforms, advisory tools and portfolio products
Scoped to your use case rather than sold as a fixed bundle
One registration covers all of them. The form asks what you are building so we can provision the right services and the right entitlement class — personal, commercial or redistribution. You do not need to fill it in once per API.
Connecting
Market Data API — five ways in
However you reach the market data service, it is the same archive underneath. REST answers questions about the past. WebSocket tells you what's happening now. The SDKs wrap both so you're writing trading logic rather than reconnection logic.
Protocol
REST API
Historical bars, tick history, symbol reference and instrument master over plain HTTP and JSON. Everything you need to seed a database, run a backtest or populate a research notebook.
A persistent stream of live ticks with volume and open interest. Subscribe to the symbols you want and receive updates as they print, rather than polling an endpoint and hoping the interval was short enough.
The shortest path from an idea to a tested one. Pull history into your analysis stack, iterate in a notebook, then point the same code at the live stream when the logic holds up.
For services and web products — a scanner that runs all session, a dashboard back end, an alerting service. Event-driven by nature, which fits a tick stream well.
C# and VB.NET, for desktop terminals and Windows trading systems — including anything already living alongside NinjaTrader or an in-house execution stack.
The REST and WebSocket interfaces are ordinary HTTP and JSON, so Go, Java, Rust, C++ or whatever your team already runs will talk to them without an SDK in the middle.
Live Greeks are easy to find. Historical Greeks are not — which is why most options research quietly recomputes them afterwards from closing prices, and quietly gets a different answer from what the screen actually showed at the time.
The Greeks History API serves stored Greeks and implied volatility for option contracts as a separate, token-authenticated REST service, so a study of how delta or IV behaved into an expiry reads the values as they stood rather than a reconstruction.
Delta, gamma, theta, vega and rho alongside implied volatility, held as history rather than derived on request — so two people running the same study get the same numbers.
IV
Implied volatility through the life of a contract
Follow IV from the day a strike lists to the day it expires, which is what any serious volatility or premium-decay study needs and what daily closes cannot give you.
{}
A plain REST service with token auth
Separate endpoint, its own authentication, ordinary JSON. Start at the auth section of the documentation and you will have a response back inside a few minutes.
∑
Same archive underneath
Computed on the same tick data the rest of the platform reads, so a Greeks study and a price study of the same expiry are describing one market, not two.
Docs and tools
Try it before you write a line
The test app calls the live API from your browser, so you can see a real response shape before committing an afternoon to an integration. The symbols reference is worth five minutes before your first request — naming is where most first calls go wrong.
Most systematic strategies don't fail in production because the logic was wrong. They fail because the data used to prove the logic was different from the data it eventually traded on — and nobody could tell, because the difference was invisible.
These are the four places that gap usually opens, and what we do about each.
Re-run a backtest a month later on a feed that reprints, and you get a different result from the same code — which makes every comparison meaningless. Our closed candles never change, so a strategy re-tested next year sees exactly the past it saw today.
02
Corporate actions only half applied
A split adjusted on the daily series but not the intraday one produces a phantom gap your model learns as a signal. Adjustments run across tick, one-minute and end-of-day together, so a strategy trained intraday isn't learning an artefact.
03
Open interest left raw across a roll
Most feeds adjust price for a contract change and leave OI untouched, which silently breaks every OI-based signal at exactly the point the market is rolling. Ours are adjusted together.
04
Continuous contracts you can trust
Long-horizon futures testing needs a continuous series, and a specific expiry for execution. Both are available side by side — TCS_I and TCSJUL19 — so the series you test on and the contract you trade are explicitly your choice, not a vendor's guess.
What gets built
Six things customers have already shipped
The pattern is consistent: the shelf covers most of what a trader needs, and the remaining ten per cent is the part that's actually theirs. That ten per cent is what the APIs are for.
A terminal of their own
Watchlists, charts and order tickets laid out the way a specific desk works, rather than the way a general-purpose platform assumes.
Scanners nobody sells
Screening logic that doesn't exist as a product — a specific combination of profile, open interest and relative volume, running across hundreds of instruments all session.
Backtesting engines
In-house frameworks fed tick or one-minute history in bulk, so the simulation runs on the same series the live system will subscribe to.
Risk and P&L dashboards
Live mark-to-market across a book, updating on ticks rather than on a refresh button, and reading the same prices the trading screen shows.
Mobile and web products
Apps that need a real feed behind them — delivered by a service you control, rather than a third-party widget you can't fix at 9:20 in the morning.
Research pipelines
Scheduled pulls into a warehouse or notebook stack, so a quant team works from one clean copy of history instead of five inconsistent exports.
Getting started
Three steps to your first tick
API access is provisioned rather than self-serve, because entitlements and licensing depend on what you're building and how the data will be used. Registration takes a couple of minutes.
01Register your interest
Tell us what you're building, which language you work in and roughly how many symbols you expect to stream. The form takes about two minutes.
02We provision your access
Our team comes back with credentials, the documentation for your protocol and SDK, and the entitlement that matches your use case — personal, commercial or redistribution.
03Build against it
Pull history over REST, subscribe over WebSocket, and reach us on chat or phone during support hours when something doesn't behave the way the docs say.
The same archive, the same adjustment rules, the same timestamps. Pix Connect is a desktop client that delivers it into charting software; the APIs deliver it into your code. A chart in NinjaTrader and a request over REST are reading the same underlying series, which is what makes it safe to prototype in one and ship in the other.
The archive runs to years of tick-by-tick and adjusted end-of-day history. How much of it your entitlement covers depends on what you're building — a research desk seeding a warehouse and a mobile app showing today's chart need very different things, and are priced accordingly. Bulk historical delivery is available separately for large one-off loads.
Personal and non-commercial use is the default. Anything beyond that — a product you sell, a dashboard for clients, a terminal for a dealing room, or any redistribution of the data — needs a commercial or redistribution licence, which we arrange with the exchange. Tell us the use case on the registration form and we'll come back with the right terms rather than the wrong ones.
Yes — through the Greeks History API, a separate REST service with its own token authentication. It serves stored delta, gamma, theta, vega and rho alongside implied volatility for option contracts, rather than recomputing them on request, which is what makes two runs of the same study agree. The documentation starts at the auth section; access is arranged through the same registration form.
API pricing is quoted rather than listed, because it depends on symbol count, history depth, live versus historical access and the licence class. That said, it starts from the same place the plans do — if you're one developer streaming a handful of instruments, expect it to look like a Pix Connect plan, not an enterprise contract.
No. The APIs are a direct route to the data with nothing in between. Plenty of customers run both — charting in NinjaTrader or AmiBroker for discretionary work, APIs for the automated side — but neither depends on the other.
Whichever you already work in — there's no advantage to switching. Python tends to suit research and backtesting, Node.js suits always-on services, and .NET suits desktop terminals and Windows systems. If your stack isn't one of those, REST and WebSocket are ordinary HTTP and JSON.
The same people who run the feed, on phone and live chat during support hours — not a ticket queue in another timezone. If a payload doesn't look the way the documentation says it should, you'll be talking to somebody who can check the feed itself.
Two minutes on the form, and our team comes back with credentials, docs and terms that match the use case — whether that's one developer with a notebook or a desk putting a product into production.