Configure Pinnacle odds drop alerts that stay useful

Choose the right PinnWire alert surface

A drop is a price decrease detected by PinnWire's engine. It is not a claim about why the price moved, and it is not a complete movement history. PinnWire keeps those meanings separate so your alert policy can be precise.

Try a focused drop query

The public demo key can test REST without signup. It is shared and capped, so use a free emailed trial key for an application or repeated tests.

curl "https://pinnwire.com/api/drops?mode=prematch&sport_id=1&min_drop_pct=2&max_drop_pct=12&markets=spread&periods=0&max_age_sec=900&limit=25&key=demo&fresh=alert-guide-1"

This asks for soccer full-match spread drops from the last 15 minutes, between 2% and 12%, with at most 25 rows. fresh is an optional cache-buster; it does not change the filter.

{
  "total": 1,
  "generated_at": "2026-08-26T10:05:12.412Z",
  "drops": [{
    "event_id": 1629725918,
    "sport_id": 1,
    "sport_name": "Soccer",
    "home": "Bentleigh Greens",
    "away": "St Albans Saints",
    "market": "spread",
    "period": 0,
    "side": "home",
    "points": -0.5,
    "from": 2.37,
    "to": 2.25,
    "drop_pct": 5.06,
    "nvp": 2.21,
    "starts": "2026-08-26T11:00:00Z",
    "is_live": false,
    "alerted": 1787738712,
    "age_s": 12
  }]
}

The REST names are intentionally straightforward: from and to are decimal prices, drop_pct is the percentage fall, side identifies the outcome, and age_s tells you how old the detection is at response time. Check generated_at before presenting a response as current.

REST odds alert filters, exactly

These query parameters apply to GET /api/drops and its alias /v1/drops. They filter PinnWire's recent in-memory drop buffer, which covers roughly the latest three hours. The default response is live drops with a 5% minimum and up to 500 rows.

Three useful starting profiles

There is no universal perfect configuration. Begin with a profile that matches the job, measure alert count and useful-alert rate, then adjust one parameter at a time. These profiles use only fields PinnWire actually supports.

These are configuration starting points, not betting instructions. A larger minimum produces fewer rows; a smaller maximum age favors recency; a sport or market filter trades coverage for a cleaner queue.

Use SSE when an alert should arrive immediately

PinnWire's SSE endpoints provide a focused push surface for detected drops. The live endpoint is /odds-drop; the prematch endpoint is /odds-drop-prematch. Both accept min_drop, measured in percentage points, with a 1% floor and a default of 5.

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

# Wait 30 seconds, then emit only if the fall still meets 7%
curl -N "https://pinnwire.com/odds-drop-prematch?key=YOUR_KEY&min_drop=7&recheck=30"

recheck is prematch-only. PinnWire waits the requested number of seconds, reads the current tracked price, and compares it with the original from_price. If the price bounced back below the threshold, that candidate is silently suppressed. An emitted frame includes rechecked_ms. Live ignores recheck.

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

data: [{"home":"…","away":"…","sect":"Spread","period":0,
        "outcome":"home","from_price":2.24,"to_price":2.10,
        "drop_pct":6.25,"nvp":2.18,"is_live":false,
        "rechecked_ms":30012}]

:ka

Frames containing drops are JSON arrays. The initial connected frame is an object, and :ka is a keep-alive comment every 25 seconds. Ignore comments and parse only data: payloads. SSE is available on Stream, Pro + Drops, and Scale plans; the free trial and demo are REST-only.

Keep the alert identity exact

Use nvp and published limits as context

Every detected drop with at least two priced outcomes carries nvp, PinnWire's no-vig decimal reference at detection time. The reciprocal 1 / nvp is the corresponding fair implied probability. If you compare a separate offered decimal price O, the simple fair-price edge estimate is O / nvp - 1. Treat it as an estimate, not a guarantee.

function fairContext(drop, offeredDecimal) {
  const nvp = Number(drop.nvp);
  if (!Number.isFinite(nvp) || nvp <= 1) return { fairProbability: null, edge: null };
  return {
    fairProbability: 1 / nvp,
    edge: offeredDecimal / nvp - 1
  };
}

console.log(fairContext({ nvp: 2.21 }, 2.30));
// { fairProbability: 0.452488..., edge: 0.04072... }

The REST drop record does not include a max limit field. If limit context is part of your policy, fetch the matching current event from /kit/v1/markets, /kit/v1/details, or /kit/v1/prematch/lines. Published spread and total rows can expose max; fields appear only where the market publishes them.

Add a cooldown and dedupe layer in your client

One event can move more than once. A robust notification worker should allow the stream to report new qualifying drops while preventing repeated messages for the same exact event, market, period, line, and side. Choose the cooldown for your product; 30 seconds below is only an example.

const lastAlert = new Map();
const COOLDOWN_MS = 30_000;

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

function acceptDrop(d, now = Date.now()) {
  const pct = Number(d.drop_pct);
  if (!Number.isFinite(pct) || pct < 3) return false;

  const key = alertKey(d);
  const previous = lastAlert.get(key) ?? 0;
  if (now - previous < COOLDOWN_MS) return false;

  lastAlert.set(key, now);
  // Periodically prune so a long-running process stays bounded.
  if (lastAlert.size > 50_000) {
    for (const [k, t] of lastAlert) if (now - t > COOLDOWN_MS * 4) lastAlert.delete(k);
  }
  return true;
}

// REST rows use event_id/market/side; SSE rows use id/market_type/outcome.
// Normalize both before calling acceptDrop().

For REST, also reject rows where age_s exceeds your notification budget even if the request used max_age_sec. For SSE, keep the stream's connected id in logs, reconnect with exponential backoff, and never assume a reconnect replays events you missed. Use REST to recover the recent buffer after a disconnect.

A production configuration workflow

1. Discover. Query a broad REST profile with min_drop_pct=1 and a modest max_age_sec to measure volume.
2. Narrow. Add sport_id, exact markets, periods, and an optional max_drop_pct one at a time. Log counts per filter.
3. Set a freshness budget. Use max_age_sec for REST and enforce age_s again before a notification or model action.
4. Choose delivery. Keep REST for query and recovery. Use live SSE for instant live drops, prematch SSE plus recheck for persistence, or the raw WebSocket for complete market updates.
5. Normalize. Match event, market, period, points, and side exactly. Preserve decimal from/to prices and the source timestamps.
6. Filter locally. Apply SSE-only client filters for sport, market, period, age, and maximum drop; then run cooldown/dedupe.
7. Verify before acting. Fetch the current matching market when you need full outcomes, published max, or a current line after a delayed notification.
8. Persist your own history. PinnWire's recent buffer is not a permanent archive. Store accepted alerts or raw updates if you need long windows, charts, or closing-line analysis.

Know the boundaries before you ship

• The drop engine detects decreases of at least 1% in decimal price and skips the dz volatility channel; it does not report every upward move.
• The REST buffer is roughly three hours and held in memory. It is not historical opening-line or closing-line storage.
• min_drop_pct is REST syntax; min_drop is SSE syntax. Both mean percentage points, not decimal fractions.
• recheck applies only to prematch SSE. It is not a REST parameter and it does not make live alerts stable.
• SSE does not provide REST's sport, market, period, maximum-age, or maximum-drop filters. Filter and dedupe in your consumer.
• nvp can be null for a one-outcome market. A drop alone is not an EV decision, a bet instruction, or proof of cause.
• Respect API rate limits and Retry-After. SSE is not counted against REST request limits, but each key has a combined cap of five SSE connections.

Odds alert configuration questions

What is the best way to configure Pinnacle odds drop alerts?

Start with PinnWire's REST drop endpoint to inspect volume, then choose a mode, minimum and optional maximum drop, sport, market, period, and maximum age. Move to SSE when you want qualifying drops pushed to your process, and add client-side cooldown and dedupe for notifications.

What is the difference between min_drop_pct and SSE min_drop?

PinnWire REST uses min_drop_pct in percentage points, such as 5 for a 5% minimum. The SSE endpoints use min_drop, also as a percentage, with a 1% floor. REST supports the broader query filters; SSE adds push delivery and prematch recheck.

How does PinnWire's prematch recheck filter work?

On /odds-drop-prematch, recheck=N waits N seconds, reads the current price again, and emits the alert only if the drop still meets min_drop against the original from_price. A bounce-back is suppressed. recheck is ignored on the live endpoint.

Does PinnWire include no-vig and limit context in a drop alert?

PinnWire drop records include nvp when at least two outcomes are priced, so 1 / nvp is the fair implied probability. The drop object itself does not include a limit field; fetch the matching current event from the PinnWire market endpoints, where published spread and total lines can include max.

How do I stop duplicate Pinnacle line movement alerts?

Use a stable key made from event ID, market, period, points, side, and optionally participant name. Store the most recent drop timestamp and suppress the same key during a strategy-specific cooldown. Keep a separate connection ID for each SSE stream and use REST to recover after disconnects.