Unusual Whales API - Intel endpoints (IntelController)

Unusual Whales API - Intel endpoints

Layer mapping: mixed.

• /market/movers → L1 partial. Top-gainers / top-losers / most-active context. SPY hunter cares which mega-caps are moving.
• /analytics/sliding + /analytics/window → L1 partial. Generic analytics computed over time windows. Underdocumented in UW; exact use-case TBD.
• /ipo-calendar → L3. New listings calendar.
• /listings → L3. New issue universe.

Five endpoints, grab-bag controller. The most important for L1 is /market/movers.

1. Base contract

Property	Value
Base URL	https://api.unusualwhales.com
Auth	Authorization: Bearer <token> header
Response envelope	{ "data": ... }
Status codes	200, 422, 500
Rate limits	Not specified

2. Endpoint matrix

#	Path	Purpose	Layer
1	GET /api/market/movers	Top gainers/losers/most-active snapshot	L1
2	GET /api/analytics/sliding	Analytics over a sliding window	L1 partial (TBD)
3	GET /api/analytics/window	Analytics over a fixed window	L1 partial (TBD)
4	GET /api/ipo-calendar	Upcoming and recent IPOs	L3
5	GET /api/listings	New equity listings universe	L3

3. GET /api/market/movers

Snapshot of three market lists: most-active, top-gainers, top-losers.

No path or query parameters documented.

Response:

{
  "data": {
    "last_updated": "ISO timestamp",
    "most_active":  [/* per-ticker rows */],
    "top_gainers":  [/* per-ticker rows */],
    "top_losers":   [/* per-ticker rows */]
  }
}

Per-row schema not detailed in docs - expect ticker, name, price, change, change_pct, volume. Verify on first fetch.

MK3 use (L1). Poll every 30s during RTH. Three derived features:

• mag7_in_top_gainers_count (0-7): how many mag7 names are in top gainers right now. Breadth check.
• spy_top_holdings_in_movers: same logic against SPY top-25.
• volume_concentration: are most-active dominated by 2-3 names?

These complement the basket-implied flow from uw-api-etfs/holdings. Movers is what’s happening; etf holdings is what should matter.

4. GET /api/analytics/sliding

Generic analytics over a sliding window (continuously recomputed).

Query parameters:

Param	Type	Required	Default	Notes
symbols	string	yes	-	Comma-separated tickers
range	string	yes	-	Time range (e.g. 1Y, 6M)
range_end	date	no	-	Optional end date
interval	string	no	DAILY	Granularity
ohlc	string	no	close	Which OHLC field to use
window_size	int	no	20	Window size in intervals
calculations	string	yes	-	Calc type(s) to perform

Response: { data: { meta: null, payload: null } } (docs use placeholder).

The calculations query parameter is undocumented in the snapshot - likely accepts sma, ema, stddev, vwap, etc. Update on first real fetch.

“Sliding” vs “Window”: sliding = continuously rolls forward (each new bar shifts the window); fixed window = static start/end range. Same shape, different semantics.

MK3 use. Possibly a server-side technical-indicator calculator. Cheaper than computing locally if it works at scale. Hold judgment until first real fetch shows actual response shape and calculation menu.

5. GET /api/analytics/window

Same parameters as sliding, but the analytics are over a fixed window rather than a continuously sliding one.

Same response shape and use case. Treat as the “give me this stat between date X and date Y” variant.

6. GET /api/ipo-calendar

Upcoming + recent IPOs.

Query parameters (likely): start_date, end_date, limit, page. Not detailed in current fetch.

MK3 use. L3 only. Mega-IPO weeks (high IPO supply) historically suppress index performance. Useful as a macro-week filter for L3 strategies. Not in MK3 scope.

7. GET /api/listings

New equity listings universe.

MK3 use. L3 only. Inclusion-effect strategies (buy a name N days before index inclusion) live off this. Not in MK3 scope.

8. Cross-endpoint workflow

Endpoint	When to call	Cache TTL
/market/movers	Every 30s RTH	30s
/analytics/sliding	On demand (per-strategy lookup)	per-strategy
/analytics/window	On demand (per-strategy lookup)	per-strategy
/ipo-calendar	Daily	1 day
/listings	Weekly	1 week

9. Nautilus integration shape (L1 only)

• UWMoversActor polls /market/movers every 30s, publishes UWMarketMovers snapshot to bus.
• Strategies subscribe and read derived breadth features at decision time.
• Analytics endpoints unlikely to be wired in until use case is proven.

10. Known gaps

• /movers per-row schema is placeholder in UW’s docs. First fetch needs to update.
• /analytics/* response is placeholder (payload: null). The calculations taxonomy is undocumented.
• No realtime push. Polling only.

11. Source URLs

• https://api.unusualwhales.com/docs/operations/PublicApi.IntelController.movers
• https://api.unusualwhales.com/docs/operations/PublicApi.IntelController.analytics_sliding
• https://api.unusualwhales.com/docs/operations/PublicApi.IntelController.analytics_window
• https://api.unusualwhales.com/docs/operations/PublicApi.IntelController.ipo_calendar
• https://api.unusualwhales.com/docs/operations/PublicApi.IntelController.listings

cortana-north-star uw-api-etfs uw-api-lit-flow 2026-05-15-mk3-setup-hunter-architecture