Skip to main content
How the API behaves across endpoints. Endpoint pages state anything specific to that endpoint.

Response freshness

Responses are always computed fresh. There is no request caching and no force_refresh parameter. Two identical requests can return identical bytes simply because the underlying data has not changed on its update cadence. To check freshness, read a timestamp field in the payload (for example tape_time, or the newest created_at), rather than comparing raw response bodies. Every response carries a unique x-request-id.

Reading response arrays

Array order is not uniform across endpoints, so each endpoint page states its order. Where an endpoint returns newest last (for example iv-rank), the current value is the last element. A few endpoints nest their rows under a key other than data: shorts volume-and-ratio uses si, and option-contract/{id}/historic uses chains.

Empty is not an error

A 200 response with an empty data array means there is no data for the inputs you sent, not that the request failed. Common causes are a date with no trading, a symbol that does not apply to that dataset, or a missing required filter (for example /api/stock/{ticker}/greeks without expiry).

Symbols and ticker types

Each endpoint states which symbol types it accepts (equities, ETFs, indices, crypto) and the expected format. Crypto pairs use the BASE-QUOTE form, for example BTC-USD. Index tickers (SPX, NDX, VIX, RUT) are supported on the greek and exposure endpoints, but not on raw quote or OHLC, where they return 422 (see the note on those endpoints).

Point-in-time and availability

For time-series endpoints, three timestamps can differ: execution time, report time, and availability time. Some fields are forward-computed and will be null on recent rows (for example realized_volatility). Daily datasets are final only after the session closes, and open interest restates the next morning. History depth and update cadence vary by endpoint and are stated on each page. For a strict point-in-time build, gate on your own first-seen ingestion time rather than re-pulling past dates.

Nullable fields

Fields that can be null, and why, are listed on each endpoint page. The common ones: greeks when the underlying is missing, underlying_price on the index tape, recent realized_volatility rows, gamma_flip, and max-pain close for NDX.

Concept to route

Use these routes rather than guessing a name (guessed names return 404). There are no volatility/skew, volatility/surface, or term-skew routes.

Rate limits

There is no per-minute request cap. REST requests are limited by how many you have in flight at once and, on plans that have one, by a request cap. Your account can have a fixed number of REST requests in flight at once, counted across all of your API tokens. API Basic, API Advanced, Whale Bundle Basic and Whale Bundle Advanced allow 3. A request over that limit returns 429 with the code concurrent_limit_exceeded, and current_limit in the body holds your limit. The rejected request does not count toward your request cap. Keep at most current_limit requests in flight, for example with a semaphore, and retry rejected requests after a short backoff with jitter. The same four plans have no daily request cap. On plans with a cap, requests after it is used up return 429 with the code daily_request_limit_hit until the cap resets. WebSocket messages count toward neither limit. For data you need continuously, stream it over one WebSocket connection instead of polling REST endpoints. WebSocket needs the Advanced tier or above and has its own connection rules.

Request headers to watch

Every response carries x-request-id, which is unique per call. Tokens with a request cap also get these usage headers on every response except a 429. Read them to manage your own rate rather than guessing.
  • x-uw-token-req-limit is your request cap. On most plans this is a daily cap.
  • x-uw-daily-req-count is what you have used toward that cap. On most plans this count resets daily at 8PM ET.
Tokens without a request cap, such as API Basic and API Advanced, do not get these two headers. Responses also carry x-uw-req-per-minute-remaining and x-uw-req-per-minute-reset, except a 429 with the code daily_request_limit_hit. These two headers are deprecated and will be removed after 2026-12-31. They always hold 1000000 and 60000 and do not reflect a limit, because there is no per-minute cap. If your code reads them, we recommend moving off them before then. The Starter plan uses a monthly quota instead of a daily one. Monthly Starter subscriptions get 25K requests per billing month, and annual Starter subscriptions get 50K requests per month. Annual plans use monthly windows anchored to the start date of your annual term. On Starter, x-uw-token-req-limit shows your monthly cap and x-uw-daily-req-count shows your usage for the current billing month. The count resets at the start of each billing month, not at 8PM ET. Only HTTP 200 responses count toward the allowance. All of your API tokens share one allowance, including tokens you have rotated.

Data Shop and limits

Data older than your plan’s lookback window is available as one-time downloads in the Data Shop. Your plan’s lookback and request quota (daily on most plans, monthly on Starter) are listed in the pricing and limits reference.

Example URLs

Each endpoint page shows one fully filled example URL and marks each parameter as path or query. Note that technical-indicator/{function} is a path segment, not ?function=.

Data retention and redistribution

You may keep and use API data for personal or internal purposes, including after you cancel. Redistributing the data to others requires a redistribution license. Contact [email protected].
Last modified on November 1, 2026