Signals

A signal is a detector's claim about one position, with its working shown. It has a signal_type from a small catalog, a strength whose meaning the catalog states per type, a confidence of low / medium / high, an expires_at, a venues list, and an evidence block whose shape depends on the type.

The trade types are built from venue prints — trades that actually happened — rather than from quotes, and only on venues that publish their trades. Each carries the venue in evidence.partner_id. trader_id is filled where the venue exposes an identity (a wallet) and is null where it does not, so a whale on one venue is a large print and on another can name the wallet behind it.

What the trade types publish, as calibrated against historical prints before release:

• whale_trade — a print of at least twice the whale threshold (the greater of $500 or eight times the position's median print), so roughly $1,000 and up on most markets. contest_phase says whether it printed before the scheduled start; pre-game whales did not move prices in testing, so their confidence is capped at medium however large they are.
• flow_imbalance — only unanimous flow: every aggressive print in the last minute one way, at least five prints and $1,000, with no single print more than half of it (a single large print is a whale, not flow).
• trade_burst — observed for calibration but not published: bursts did not beat ordinary trading in testing. Its catalog entry stays so a stored type string still resolves.
• trade_through and volume_spike — published at their initial thresholds while they are evaluated; expect their calibration to change.

Read the catalog rather than this table: GET /signals/types is open to any key on any plan and states each type's strength_semantics and evidence_fields. Beta types are served only when you ask for them.

Signals expire in seconds, so the WebSocket is the intended surface; the REST feed is for backfill and one-off queries. Subscribe on the signal channel with the same filters:

copy{ "action": "subscribe", "channel": "signal",
  "league_ids": ["lg_nba"],
  "types": ["arbitrage"],
  "min_confidence": "medium",
  "min_strength": 50,
  "include_beta": false }

Every filter is optional: a subscription with none receives signals for every contest, which is what a monitor wants. strength is 0–100 on every type. Filters are applied server-side per subscriber, so you only pay bandwidth for signals you would act on.

copy{ "type": "signal.update",
  "contest_id": "ct_abc123",
  "league_id": "lg_nba",
  "signals": [ /* the same objects GET /flow/v1/signals returns */ ],
  "timestamp": "2026-09-22T03:01:46.180Z" }

Each event is a snapshot of that contest's current signals, not a delta: replace whatever you hold for contest_id. An empty signals array means the contest's signals cleared. Events are sent only when the set changes. When every signal in a change fails your filters you get nothing — except that a clear (an empty array) reaches every subscriber of the contest, so treat it as a no-op for a contest you hold nothing for. Still drop a signal yourself once its expires_at passes.

Everything else about the connection — the key in the query string, heartbeats, limits, the entitlement_required error — is on the Streaming page.

• Detection is not advice. A signal reports a priced relationship and shows its evidence; venue rules, settlement-source differences and your own limits are yours to check.
• Use the evidence, not just the strength. For arbitrage, trade off after_fee_roi and size to best_max_investment; the full legs are on GET /arbitrages by arbitrage_id.
• Respect expires_at. A signal past it is history, whatever the feed still holds.

• Arbitrage — the full legs behind an arbitrage signal→
• Streaming — the signal channel, live→
• Placing orders — act on it→