Trading & Capital Markets
Economic Event Intelligence API
Every broker shows an economic calendar. Almost none of them tell the trader what the release has historically done to the instrument they are holding.
- Forex brokers
- Trading platforms
- Financial terminals
- Investment apps
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
The standard economic calendar is a table of dates, forecasts and a one-to-three flame impact rating that nobody has validated. It is table stakes, it is identical across every platform, and it is close to useless at the moment a trader actually needs it — which is when a number has just printed and the market is moving.
The useful version answers a different question. Not 'what is scheduled', but 'this print came in 0.4 standard deviations above consensus; the last forty times that happened, EURUSD moved this much within thirty minutes, and here is the dispersion of those outcomes'.
That is a data engineering problem more than a modelling one. You need a clean calendar, a history of consensus forecasts as they stood before each release, the actual prints including revisions, and aligned price history across your instrument universe. Assembling that archive is the work; once you have it, the surprise measurement and the reaction statistics are straightforward.
Who buys this
Forex brokers, Trading platforms, Financial terminals, Investment apps
What the API returns
What comes back
- Forward calendar with consensus, previous value and revision history
- A measured impact score per event and instrument, derived from history rather than asserted
- Surprise score in standard deviations once the actual value prints
- Historical reaction distribution: median move, dispersion and direction consistency
- Expected volatility windows around scheduled releases
- Release-time alerts delivered within seconds of publication
- Country, currency and sector tagging for filtering
- Revision tracking so a restated figure does not silently corrupt your history
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/calendar | Upcoming events, filterable by country, currency and impact |
| GET | /v1/events/{id} | Full detail for one event including consensus and history |
| GET | /v1/events/{id}/reaction/{symbol} | Historical reaction of an instrument to this event |
| GET | /v1/surprise | Recent prints ranked by surprise magnitude |
| GET | /v1/volatility-windows | Periods of expected elevated volatility ahead |
| WS | /v1/stream | Push actual values the moment they are released |
Request and response
illustrativeRequest
{
"event_id": "us-nfp-2026-11",
"symbol": "EURUSD",
"window_minutes": 30,
"lookback_releases": 40
}Response
{
"event": {
"id": "us-nfp-2026-11",
"name": "US Non-Farm Payrolls",
"country": "US",
"scheduled_for": "2026-11-06T13:30:00Z",
"consensus": 178000,
"previous": 165000,
"measured_impact": { "symbol": "EURUSD", "score": 87, "rank": 2 }
},
"historical_reaction": {
"releases_analysed": 40,
"median_abs_move_pips": 41.6,
"p90_abs_move_pips": 96.3,
"direction_consistency": 0.64,
"by_surprise_bucket": [
{ "bucket": "> +1.0 sd", "n": 7, "median_move_pips": -68.2 },
{ "bucket": "-1.0 to +1.0 sd", "n": 24, "median_move_pips": 12.1 },
{ "bucket": "< -1.0 sd", "n": 9, "median_move_pips": 74.9 }
]
},
"expected_volatility_window": {
"from": "2026-11-06T13:28:00Z",
"to": "2026-11-06T14:15:00Z"
}
}Where the data comes from
| Official statistical releases | Primary publications from statistical agencies and central banks, which is where the actual numbers originate |
| Consensus forecast data | Licensed survey data — and critically, the consensus as it stood before each historical release, not a restated figure |
| Your price history | Minute or tick data for the instruments you cover, so reactions are measured on the prices your own users trade |
| Revision history | Many series are revised after publication; without this the surprise measurement is wrong |
| Central bank communications | Speeches, minutes and decisions, which often move markets more than scheduled data |
| Holiday and session calendars | Reaction statistics are not comparable across thin and normal liquidity periods |
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.
- Surprise scoring normalised in standard deviations against the historical dispersion of that specific series
- Impact scores measured from realised volatility around past releases, never assigned by hand
- Reaction distributions reported with sample size and dispersion so a thin sample is visible rather than hidden
- Separate handling of initial prints and revisions, since markets respond to the first number
- Event clustering to detect when several releases land close enough together to confound attribution
- Outlier detection so one crisis-period reaction does not dominate a median
- Backtesting of the volatility-window predictions against realised volatility
- Continuous monitoring for schedule changes and publication delays
What it changes for the business
A calendar people actually use
Reaction statistics turn a reference table into something a trader opens before a position decision.
Risk messaging
Volatility windows let you warn users ahead of a release rather than explaining a gap after it.
Engagement timing
Scheduled releases are a legitimate, non-pushy reason to send a notification.
Support deflection
Much of the 'why did my stop trigger' traffic is explained by a release the user did not know about.
How it fits into your product
How it embeds
- Calendar widget and event-detail components, or raw JSON if you have your own front end
- WebSocket push for actual values within seconds of publication
- Webhooks into your alerting system for pre-release and post-release notifications
- Per-instrument reaction endpoints so the statistics match what the user is holding
- Localisation for event names and country labels across your supported languages
- Entitlement controls so deeper history can be reserved for funded accounts
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 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
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
How quickly do actual values arrive?
Within a few seconds of official publication for major releases. The architecture polls primary sources directly rather than waiting for a downstream aggregator, because the delay in that chain is exactly when the move happens.
Do you need our price data?
For the reaction statistics, yes — or a licensed equivalent. The whole point is measuring what happened to the instruments your users trade, on the prices they trade at. The calendar itself works without it.
Is the impact rating just copied from other calendars?
No. It is computed from realised volatility around past releases of that series, per instrument. That is why the same event can carry a different impact score for EURUSD than for gold, which the conventional flame rating cannot express.
What about unscheduled events?
Central bank interventions, emergency decisions and geopolitical shocks are not forecastable from a calendar. We can ingest them as they happen and attach them to the timeline, but we would not pretend to predict them.
Can we show this to retail clients?
Yes, with the usual caution that historical reactions are measurements rather than forecasts. We would present sample sizes and dispersion openly so the figures are not read as a promise.
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.
Market Sentiment & Positioning API
Aggregated sentiment and positioning estimates by instrument, delivered as a feed your platform can display or trade against.
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.
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.