How to detect Pinnacle odds drops without alert fatigue

What a Pinnacle odds drop tells you

An odds drop is a decrease in decimal price for one outcome on one line. A move from 2.10 to 1.95 is a 7.14% price drop:

The shorter price implies a higher probability. That makes a Pinnacle move useful for line-movement monitoring, model calibration, market surveillance, and triggering a fresh comparison elsewhere.

It is still only a signal. It does not reveal who caused the move, guarantee that the new price is correct, or guarantee that a different price is profitable. A clean workflow treats the alert as a reason to inspect the market—not as an automatic instruction to bet.

Why PinnWire is the cleanest starting point

PinnWire is an independent real-time Pinnacle odds API with server-side drop detection. It tracks each outcome through market updates, ignores unchanged versions and non-price volatility signals, converts the prices to decimal, detects falls of at least 1%, and attaches event and fair-price context.

That removes the most failure-prone part of an odds movement alerts API from your application. You do not have to maintain a full previous-price book just to decide whether to < from. You consume derived drops through two focused surfaces:

The REST buffer holds roughly three hours, up to the service buffer cap. Store the records you need for longer research. For every raw live and prematch market update rather than derived drops, PinnWire also offers an optional Pinnacle WebSocket API.

The anti-fatigue filter stack

Good alerting is progressive. Apply cheap, objective filters first; add strategy-specific ranking afterward.

Thresholds should differ by workflow

A single percentage across every sport and market usually produces poor results. Live totals can reprice frequently; a prematch full-game moneyline may move less often. Start conservatively, record everything your filters accept, and tune from your own observed distribution.

Use nvp as fair-price context

Every standard PinnWire drop record includes nvp, the no-vig decimal fair price for that outcome. Its reciprocal is the fair implied probability:

nvp helps distinguish offered-price movement from the fair estimate embedded in the full market. It is an analytical baseline, not ground truth. Learn more in the no-vig fair odds API guide.

Limits need explicit treatment

Market capacity matters to many strategies, but the current PinnWire drop record does not expose a field named limit. Do not write filtering code that assumes it exists. If a minimum stake capacity is mandatory, enrich the alert from the relevant current market snapshot and inspect its available max value, then apply your threshold. Field availability varies by market, so handle a missing value explicitly.

Cooldown is a routing policy, not detection

PinnWire deduplicates unchanged market versions before drop detection, but genuine successive reprices can still create successive alerts. That is correct market data. Your notification layer can suppress repeated messages with a cooldown keyed by:

Keep storing the accepted raw alerts even when the human notification is cooled down. That preserves the movement path for analysis.

Tune the signal with the REST drops buffer

REST is the fastest way to see whether a filter is too broad. This request asks for recent live soccer moves of 3% to 15%, only full-match moneylines and totals, no older than 90 seconds, capped at 50 rows:

curl "https://pinnwire.com/api/drops?mode=live&sport_id=1&min_drop_pct=3&max_drop_pct=15&markets=moneyline,total&periods=0&max_age_sec=90&live=1&limit=50&key=demo&fresh=alert-test-1"

The live=1 filter is separate from mode: mode selects the detection buffer, while live=1 rejects a row whose recorded start time is still ahead. On the live buffer it is usually an extra guard.

REST payload names

{
  "total": 1,
  "generated_at": "2026-08-26T10:15:30.000Z",
  "drops": [{
    "event_id": 1629725918,
    "sport_id": 1,
    "sport_name": "Soccer",
    "home": "Home Team",
    "away": "Away Team",
    "league": "Example League",
    "market": "total",
    "period": 0,
    "side": "over",
    "points": 2.5,
    "from": 2.10,
    "to": 1.98,
    "drop_pct": 5.71,
    "nvp": 2.04,
    "is_live": true,
    "alerted": 1787739328,
    "age_s": 2
  }],
  "meta": {
    "mode": "live",
    "events_in_store": 600,
    "tracked_outcomes": 120000
  }
}

The values above are illustrative; names and prices change with the live feed. Check generated_at and each row’s age_s before displaying a result as current.

Move to SSE when the filters are ready

SSE pushes detected drops without polling. Use the live stream for in-play movement and the prematch stream for upcoming fixtures:

curl -N "https://pinnwire.com/odds-drop?min_drop=3&key=YOUR_KEY"

curl -N "https://pinnwire.com/odds-drop-prematch?min_drop=3&recheck=20&key=YOUR_KEY"

min_drop has a 1% floor and defaults to 5%. On prematch only, recheck=N holds a candidate for N seconds, reads the current outcome price again, and emits only if the drop still clears the threshold against the original price. A bounced-back candidate is suppressed. Confirmed records include rechecked_ms. The live endpoint ignores recheck.

SSE payload names are intentionally different

After a connection event, each drop message is a JSON array. SSE uses the stream-oriented names id, sect, outcome, from_price, and to_price. Both SSE and REST already include drop_pct and nvp.

data: {"type":"connected","id":"..."}

data: [{
  "id":1629725918,
  "sport_id":1,
  "sport":"Soccer",
  "home":"Home Team",
  "away":"Away Team",
  "sect":"Total",
  "market_type":"total",
  "period":0,
  "outcome":"over",
  "points":2.5,
  "from_price":2.10,
  "to_price":1.98,
  "drop_pct":5.71,
  "nvp":2.04,
  "is_live":true
}]

Keep-alive comments arrive about every 25 seconds; SSE clients ignore them automatically. Drop streams are available on Stream, Pro + Drops, and Scale. Each key can hold up to five SSE connections, with the oldest closed if a sixth is opened.

Complete Node.js consumer with cooldown and ranking

This consumer relies on PinnWire for server-side detection and minimum-drop filtering. Locally, it applies the market, period, freshness, no-vig, and cooldown rules that are specific to your notification workflow.

npm install eventsource

import { EventSource } from "eventsource";

const key = process.env.PINNWIRE_KEY;
if (!key) throw new Error("Set PINNWIRE_KEY to your PinnWire key");

const MIN_DROP = 3;
const MAX_AGE_SECONDS = 30;
const COOLDOWN_MS = 90_000;
const ALLOWED_MARKETS = new Set(["moneyline", "spread", "total"]);
const ALLOWED_PERIODS = new Set([0]);
const notifiedAt = new Map();

const url = new URL("https://pinnwire.com/odds-drop-prematch");
url.searchParams.set("key", key);
url.searchParams.set("min_drop", String(MIN_DROP));
url.searchParams.set("recheck", "20");

function alertKey(d) {
  return [d.id, d.market_type, d.period, d.outcome, d.points ?? ""].join("|");
}

function fairProbability(d) {
  return Number(d.nvp) > 1 ? 1 / Number(d.nvp) : null;
}

function shouldNotify(d) {
  if (!ALLOWED_MARKETS.has(d.market_type)) return false;
  if (!ALLOWED_PERIODS.has(Number(d.period))) return false;
  if (Number(d.drop_pct) < MIN_DROP) return false;

  // SSE carries epoch seconds in alerted.
  const age = Date.now() / 1000 - Number(d.alerted);
  if (!Number.isFinite(age) || age > MAX_AGE_SECONDS + 20) return false;

  const id = alertKey(d);
  const now = Date.now();
  if (now - (notifiedAt.get(id) ?? 0) < COOLDOWN_MS) return false;
  notifiedAt.set(id, now);
  return true;
}

const stream = new EventSource(url);

stream.onmessage = (message) => {
  const payload = JSON.parse(message.data);
  if (!Array.isArray(payload)) return; // ignores the connected object

  for (const d of payload) {
    if (!shouldNotify(d)) continue;

    const fair = fairProbability(d);
    console.log({
      event: `${d.home} vs ${d.away}`,
      market: `${d.sect} · period ${d.period}`,
      selection: `${d.outcome}${d.points == null ? "" : ` ${d.points}`}`,
      move: `${d.from_price} → ${d.to_price}`,
      drop_pct: d.drop_pct,
      no_vig_fair_price: d.nvp,
      no_vig_fair_probability: fair,
      rechecked_ms: d.rechecked_ms ?? null,
    });
  }
};

stream.onerror = () => {
  // EventSource reconnects automatically. Backfill from /api/drops after a
  // long disconnect if your application cannot tolerate missed alerts.
  console.error("PinnWire SSE disconnected; waiting for reconnect");
};

The example adds 20 seconds to its age allowance because the prematch recheck=20 intentionally delays confirmed delivery. In production, prune old entries from notifiedAt, persist alerts before sending notifications, and route them through a queue if downstream chat, email, or push services can fail.

A production pattern that stays quiet and trustworthy

1. Measure first. Poll filtered REST data or record the SSE stream for several days before choosing notification thresholds.
2. Keep live and prematch policies separate. Different movement speeds deserve different minimums, cooldowns, and routes.
3. Store before notifying. A cooldown should reduce human interruptions without deleting the underlying observation.
4. Backfill after disconnects. Query /api/drops with a tight max_age_sec, then deduplicate against stored alert keys and timestamps.
5. Honor freshness. REST includes generated_at and age_s. SSE includes alerted epoch seconds.
6. Use the correct schema. Normalize REST and SSE into one internal shape at ingestion instead of mixing from with from_price.
7. Enrich only when needed. Fetch current event markets when your decision requires stake capacity or a full market comparison.
8. Evaluate outcomes. Track whether moves persisted, reverted, or improved by the close. Tune on evidence from your own use case.