Price an option (Black-Scholes)
Black-Scholes price and Greeks for one option, given the inputs. POST rather than GET because it is pure compute over caller-supplied inputs - spot, strike, days to expiry, rate, vol, right - with no stored resource to fetch. The response echoes every assumption it was computed under, so the number is reproducible rather than a bare figure. delta/gamma/theta/vega/rho are per one-share unit; theta is per calendar day, vega and rho per one percentage point.
Black-Scholes price and Greeks for one option, given the inputs. POST rather than GET because it is pure compute over caller-supplied inputs - spot, strike, days to expiry, rate, vol, right - with no stored resource to fetch. The response echoes every assumption it was computed under, so the number is reproducible rather than a bare figure. delta/gamma/theta/vega/rho are per one-share unit; theta is per calendar day, vega and rho per one percentage point.
Authorization
ApiKeyAuth analytics: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: analytics:read
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Inputs for a single-option Black-Scholes price and Greeks.
Response Body
application/json
application/json
application/json
application/json
application/json
application/json
application/json
curl -X POST "https://example.com/v1/analytics/option-price" \ -H "Content-Type: application/json" \ -d '{ "spot": 1, "strike": 1, "expiryDays": 1, "rate": 0, "vol": 1, "type": "call" }'{ "data": { "price": 0, "greeks": { "delta": 0, "gamma": 0, "theta": 0, "vega": 0, "rho": 0 }, "assumptions": { "model": "black-scholes", "spot": 0, "strike": 0, "expiryDays": 0, "timeToExpirationYears": 0, "riskFreeRate": 0, "volatility": 0, "dividendYield": 0, "optionType": "call" } }, "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 sentiment source leads GET
The measured lead relationship for each sentiment source and subject class: bestLagDays (the lag at which the source shows peak correlation with subsequent price movement), peakCorrelation, sampleSize, and the DERIVED isPromotionEligible verdict. Published together so a consumer can see WHY a source is or is not trusted to LEAD price rather than merely coincide with it - and apply their own threshold if they disagree. No competitor exposes this.
Search instruments GET
Two searches share this endpoint, and exactly one must be requested. Supply query for free-text search across symbols and display names; delisted instruments are retained and returned, so a historical study is not silently survivorship-biased, and asOf resolves symbols as they were mapped on that date. Supply brokerCode together with broker for the REVERSE lookup: given an identifier off a broker statement, which instrument is it. That is the direction a reconciling consumer travels, and the match is exact rather than fuzzy. Supplying both, or neither, is refused with 400 rather than resolved in favour of one.