Loading…
Loading…
Pulse Markets tells you what was known on a date, not merely what is true now. A corporate action we learned about in June is invisible to a query asked as of March, even though its effective date is earlier. That is the difference between a backtest you can trust and one that quietly cheats.
Try it against sandbox, no signup:
curl -H "Authorization: Bearer $PULSE_SANDBOX_KEY" \
"https://sandbox.markets.pulseline.io/v1/instruments?query=AAPL"Sandbox returns real historical data on its own separate allowance.
GET /v1/instruments/{id}/corporate-actions?asOf=2026-03-01On 1 March we had not yet learned of the split. A backtest running on this date is entitled to exactly this answer, and nothing more.
Raw prices are never rewritten. Adjustment is derived at read time from the corporate action set, so you can always ask for either, and the action that caused the discontinuity is one query away on the same instrument id.
| Session | Raw closeadjusted=false | Adjusted closeadjusted=true |
|---|---|---|
| 2026-02-17 | 942.40 | 94.24 |
| 2026-02-18 | 951.05 | 95.10 |
| 2026-02-19 | 963.70 | 96.37 |
| 2026-02-20 split effective | 96.85 | 96.85 |
| 2026-02-21 | 98.12 | 98.12 |
The raw series drops from 963.70 to 96.85 overnight with no economic change. The adjusted series is continuous, and the action that explains it is queryable on the same instrument id. One call, no join.
Each of these answers a documented complaint about an existing vendor. They are product decisions, not marketing lines.
Rate limits hit during development is the single most-cited friction with market-data APIs. Sandbox returns real historical data on its own allowance, so learning the API never touches what you pay for.
Set adjusted=true and the action set is applied server-side. The actions themselves are queryable on the same instrument id. There is no second feed to buy and no join for you to maintain.
Every response carries adjusted, actionSetVersion, asOf and source. Re-request the same version and the numbers are identical, permanently, even after a later restatement.
Freshness is asserted per response, not per product. When a dataset is behind you get stale: true with a real asOf. A truthful old number beats a fabricated fresh one.
Instruments that failed stay queryable, and instrument symbols are effective-dated, so a ticker change or a reused ticker resolves correctly as of a date. Dropping delisted names is what manufactures survivorship bias.
Every response carries X-RateLimit-Limit, -Remaining and -Reset, and the dashboard shows usage over time. Discovering a limit by crashing into it is a design choice, and not one we made.
You need this before you build on it, not after.
The point-in-time guarantee is strongest going forward from our own ingest. For every fact we ingested ourselves we know exactly when we learned it, and that has been true since ingest began.
For history predating our own ingest, the knowledge timestamp reflects when we backfilled the record, not when the market first learned it. So deep historical as-of reads are not equivalent to a certified vendor point-in-time archive. Achieving that over decades requires a data source that itself retains the original knowledge timestamps, which is a subscription we do not currently hold.
We would rather tell you the boundary than let you find it inside a backtest. If you need certified point-in-time depth over a specific window, ask us and we will tell you honestly whether we cover it.
Real data, its own allowance, no card. Move to a live key when you are ready, and see the quota maths before you commit to anything.