Trading & Capital Markets
Market Sentiment & Positioning API
Traders want to know what everyone else is doing. You already hold a large part of that answer in your own order book — it just needs to be aggregated safely and presented well.
- Brokers
- Prop firms
- Trading apps
- Research terminals
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Sentiment displays are one of the highest-engagement features on a retail trading platform, which is why almost every large broker runs one. The appeal is simple: a trader deciding whether to buy EURUSD wants to know whether the crowd is long or short, and whether that has been changing.
The catch is that doing it properly requires care. Aggregated client positioning is commercially sensitive, individually identifying, and in some jurisdictions regulated. A naive implementation leaks information about your book, or about individual large clients, or both.
The build is therefore as much about aggregation rules and privacy thresholds as about the sentiment calculation itself. Minimum cohort sizes, noise floors, delayed publication for thin instruments and careful handling of concentrated positions are what make the feature safe to ship — and they are the parts most teams discover late.
Who buys this
Brokers, Prop firms, Trading apps, Research terminals
What the API returns
What comes back
- Long/short ratio by instrument, with minimum-cohort suppression applied
- Positioning change over configurable windows
- Average position size distribution in buckets, never individual positions
- Crowding score flagging unusually one-sided books
- Sentiment divergence against price direction
- Optional external sentiment inputs from permitted public sources
- Historical sentiment series for charting and backtesting
- Instrument-level data quality flags where the cohort is too thin to publish
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/sentiment/{symbol} | Current positioning for one instrument |
| GET | /v1/sentiment | Positioning across your full instrument universe |
| GET | /v1/sentiment/{symbol}/history | Historical sentiment series |
| GET | /v1/crowding | Instruments with unusually one-sided positioning |
| POST | /v1/ingest | Your anonymised position snapshots, pushed on a schedule |
| WS | /v1/stream | Live sentiment updates as positioning shifts |
Request and response
illustrativeRequest
{
"symbol": "XAUUSD",
"window": "24h",
"include_history": true
}Response
{
"symbol": "XAUUSD",
"as_of": "2026-10-21T15:00:00Z",
"cohort_size": 4182,
"positioning": {
"long_pct": 71.4,
"short_pct": 28.6,
"change_24h_pct_points": 6.2,
"crowding_score": 78,
"crowding_band": "elevated"
},
"size_distribution": [
{ "bucket": "micro", "share": 0.41 },
{ "bucket": "small", "share": 0.38 },
{ "bucket": "medium", "share": 0.17 },
{ "bucket": "large", "share": 0.04 }
],
"divergence": { "price_direction": "down", "sentiment_direction": "up",
"diverging_since": "2026-10-18" },
"quality": { "publishable": true, "suppressed_reason": null }
}Where the data comes from
| Your own anonymised positioning | Aggregated snapshots from your book, pushed on a schedule — never individual client records |
| Published exchange positioning data | Where available for the instrument class, as an independent cross-check |
| Permitted public sentiment sources | Only sources whose terms allow commercial redistribution of derived measures |
| Your price history | Needed to compute divergence between sentiment and price |
| Instrument reference data | Contract sizes and tick values, so size buckets are comparable across instruments |
| Cohort statistics | Account counts per instrument, which drive the suppression thresholds |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Minimum cohort thresholds below which nothing is published, protecting both clients and your book
- Position-size bucketing rather than raw notional, so no single large account is identifiable
- Winsorising of extreme positions so one client cannot move the published ratio
- Crowding scores computed against each instrument's own historical distribution
- Divergence detection comparing sentiment direction to realised price direction
- Optional publication delay for thin instruments, configurable per class
- Validation that aggregate figures cannot be reverse-engineered across overlapping time windows
- Monitoring for sudden cohort collapse, which is usually a data pipeline failure rather than a market event
What it changes for the business
High-engagement feature
Sentiment widgets consistently rank among the most-viewed components on retail platforms.
No raw data exposure
Aggregation and suppression rules are built in, so the feature ships without leaking your book.
Research cross-sell
Sentiment pairs naturally with pattern and calendar research as one bundled module.
Internal risk view
The same aggregation gives your risk desk a cleaner picture of concentration than most internal tooling.
How it fits into your product
How it embeds
- Push anonymised snapshots to us on a schedule, or we run the aggregation inside your own infrastructure
- Ready-made gauge and history widgets, or raw JSON for your own components
- WebSocket stream for live updates in active charts
- Configurable suppression thresholds set by your compliance team, not by us
- Deployment entirely within your environment where data residency requires it
- Per-tier entitlements so historical depth can be a premium feature
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 9 weeksDiscovery
Week 1
A short, focused scoping round: the inputs available, the output you need, expected volume and the latency budget.
Prototype on your data
Weeks 2–3
A callable endpoint running against a sample of your real records, so you can judge accuracy before committing to the full build.
Production build
Weeks 4–8
Hardening, documentation, authentication, monitoring and the throughput work needed to run this at your volume.
Integration and handover
Week 9
Integration support for your team, load testing and an agreed support arrangement.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Does our client data leave our systems?
Only if you want it to. The usual arrangement for this build is deployment inside your own infrastructure, where the aggregation runs next to your data and only aggregate figures are served. If you prefer a hosted service, you push pre-anonymised aggregates and we never see individual positions.
Can competitors infer our book from this?
That is the specific risk this design guards against. Minimum cohorts, size bucketing, extreme-position winsorising and optional publication delay all exist to prevent it. We also test explicitly that overlapping time windows cannot be differenced to recover individual positions.
What if we are too small for meaningful cohorts?
Then some instruments will be suppressed, and the API says so rather than publishing noise. For a smaller book we would usually recommend starting with your most-traded ten or twenty instruments.
Is this a trading signal?
We would not present it as one. Crowded positioning is an observation, and the relationship between crowding and subsequent returns is unstable. It is context, not a recommendation.
Can we blend in external sentiment?
Where the source permits commercial use of derived measures, yes. We check the terms of each source during discovery and tell you which ones can and cannot be included.
Related blueprints
Forex Technical Analysis API
Chart patterns, support and resistance levels and trade setups, delivered as a white-label research module for your trading platform.
Trading Journal Analytics API
Behavioural analysis of closed trades that tells a trader what is actually costing them money, as a retention feature inside your platform.
Economic Event Intelligence API
An economic calendar with impact scoring, surprise measurement and the historical reaction of each instrument to each release.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.