Pulse Markets
Pulse Markets docsGet a correlation matrix
A pairwise correlation matrix over the stored daily returns of 2-20 instruments. Closes are read adjusted and converted to LOG returns (a correlation of price levels is spurious), then every pair is aligned on the dates all instruments share before correlating - pearson or spearman. The honesty is in the sample: each instrument reports its own observation count, assumptions.alignedObservations reports the common N behind every coefficient, and an instrument with too few overlapping bars is reported with that low count rather than dropped or padded with zeros. Fewer than two instruments with usable data is refused with invalid_request rather than answered with a fabricated matrix.
A pairwise correlation matrix over the stored daily returns of 2-20 instruments. Closes are read adjusted and converted to LOG returns (a correlation of price levels is spurious), then every pair is aligned on the dates all instruments share before correlating - pearson or spearman. The honesty is in the sample: each instrument reports its own observation count, assumptions.alignedObservations reports the common N behind every coefficient, and an instrument with too few overlapping bars is reported with that low count rather than dropped or padded with zeros. Fewer than two instruments with usable data is refused with invalid_request rather than answered with a fabricated matrix.
Authorization
ApiKeyAuth correlations:readPresent your API key as a bearer token: Authorization: Bearer pk_live_....
Two environments are issued per account. A pk_test_ sandbox key returns the SAME real historical data as a live key and does NOT consume your LIVE allowance, so learning the API is free. It has its own separate windows and can be rate limited on them. A pk_live_ key reads against your allowance.
Keys carry explicit scopes (instruments:read, prices:read, actions:read, fx:read, earnings:read, options:read, news:read, sentiment:read, events:read, analytics:read, correlations:read, technicals:read, macro:read) and are enforced fail-closed, so a leaked key is bounded to what it was issued for. Revocation is immediate.
In: header
Scope: correlations:read
Query Parameters
Comma-separated instrument ids, 2-20. Duplicates are collapsed and order is preserved. Fewer than 2 distinct usable instruments is refused rather than answered with a fabricated matrix.
1 <= lengthLookback window in CALENDAR days over which stored daily closes are read and converted to returns. Trading days are roughly 70% of this. Defaults to 90, bounded 20-504.
20 <= value <= 50490pearson measures linear co-movement of the return series; spearman measures monotonic co-movement via ranks and is robust to outliers. Both run on LOG returns, never price levels (a correlation of two trending price series is spurious).
"pearson"Value in
- "pearson"
- "spearman"
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/v1/correlations?instrumentIds=string"{ "data": { "pairs": [ { "assetA": "string", "assetB": "string", "correlation": 0 } ], "instruments": [ { "instrumentId": "string", "observations": -9007199254740991 } ], "assumptions": { "method": "pearson", "lookbackDays": -9007199254740991, "alignedObservations": -9007199254740991, "returnType": "log" } }, "meta": { "asOf": "string", "source": "string", "stale": true }}{ "error": { "code": "invalid_request", "message": "string", "docsUrl": "http://example.com", "details": { "property1": [ "string" ], "property2": [ "string" ] } }}{ "error": { "code": "invalid_request", "message": "string", "docsUrl": "http://example.com", "details": { "property1": [ "string" ], "property2": [ "string" ] } }}{ "error": { "code": "invalid_request", "message": "string", "docsUrl": "http://example.com", "details": { "property1": [ "string" ], "property2": [ "string" ] } }}{ "error": { "code": "invalid_request", "message": "string", "docsUrl": "http://example.com", "details": { "property1": [ "string" ], "property2": [ "string" ] } }}{ "error": { "code": "invalid_request", "message": "string", "docsUrl": "http://example.com", "details": { "property1": [ "string" ], "property2": [ "string" ] } }}{ "error": { "code": "invalid_request", "message": "string", "docsUrl": "http://example.com", "details": { "property1": [ "string" ], "property2": [ "string" ] } }}Get price series for many instruments GET
The supported path for analytical workloads. One call rather than an N+1 fan-out across instruments, capped at 500 ids. Adjustment provenance is returned per instrument, since each has its own independent action-set counter.
List earnings across the market GET
The earnings calendar for every instrument that reports in a date window, earliest first. The market-wide counterpart to the per-instrument read, for callers building a calendar or scanning for upcoming catalysts rather than asking about one name. from and to are both REQUIRED and the span is capped at 365 days: an unbounded universe-wide scan is refused rather than served slowly. instrumentId narrows the same operation to one name. Every row carries the resolved symbol and display name, so a caller reading the whole market never has to fan out one instrument lookup per row. Each row otherwise carries only what the calendar table holds - report date, session and fiscal period. There is deliberately no EPS estimate, actual, consensus or confirmation flag: the ingest does not carry them, and returning nulls in their place would let a caller mistake absence for a measured zero.