Pulse Markets
Pulse Markets docsGet an FX rate
The rate for a currency pair on a date. Returns 404 for a date not yet ingested rather than interpolating one - a fabricated rate is worse than an honest absence.
The rate for a currency pair on a date. Returns 404 for a date not yet ingested rather than interpolating one - a fabricated rate is worse than an honest absence.
Authorization
ApiKeyAuth fx: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: fx:read
Path Parameters
Base currency, ISO 4217, e.g. GBP.
3 <= length <= 3Quote currency, ISO 4217, e.g. USD.
3 <= length <= 3Query Parameters
The rate date.
^\d{4}-\d{2}-\d{2}$Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X GET "https://example.com/v1/fx/str/str?date=string"{ "data": { "base": "string", "quote": "string", "rateDate": "string", "rate": 0, "asOf": "string", "source": "string" }, "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" ] } }}List event-reaction coverage GET
Which instruments have enough measured reaction history to be worth acting on, as ONE aggregate rather than one call per instrument. Per instrument: reactionCount (the N), firstEventDate, lastEventDate and the observationWindowDays they span. Both are published because neither alone is the claim - six reactions inside one month is six measurements of a single market regime, not a history - so a caller can require a count AND a span via minReactions and minWindowDays. The filters are echoed in assumptions, so any returned set is reproducible. Only instruments with a current symbol row are returned; an instrument we cannot name is not a usable answer. Screening a universe with the per-instrument event-reactions endpoint costs one request per candidate, which is exactly what this endpoint exists to remove. eventClasses takes a comma-separated SET (`earnings,fomc,cpi`) because measurable history is a union: an ETF or a crypto never reports earnings but can have years of measured macro reactions, and asking one class at a time made that history invisible.
Read implied volatility in bulk GET
Each requested instrument's most recent 30-day at-the-money implied volatility, annualised, as ONE read rather than one call per symbol. The thirty-day point rather than the front expiry, whose IV is dominated by whatever is happening this week and is therefore a poor measure of what the market expects over a holding period. Every row carries its own asOfDate: implied volatility is a statement about the NEXT thirty days, so a stale reading is not a slightly-worse answer, it is an answer to a different question. An instrument with no fresh snapshot is ABSENT from the result, never present with a zero, because a zero would be indistinguishable from a claim that the market prices this at no volatility.