When Pinnacle odds bounce back: how to check current EV

What does it mean when Pinnacle odds bounce back?

Imagine a prematch decimal price moves from 2.20 to 2.05. That fall is a shortening signal: the market price became smaller. If it later moves to 2.16, the price has bounced back toward the starting point. A move all the way to 2.20 is a full reversion; a move to 2.16 is a partial reversion.

The first drop does not disappear from history. It tells you what the tracked outcome did at the time it crossed your threshold. The bounce is a second observation that says the price is now different. Treating both observations as one unchanged signal is how a movement alert turns into a stale decision.

Separate the original EV signal from current EV

There are two different calculations. The first uses the fair-price reference available when you noticed the move. The second uses the latest aligned market state and a current offer. They should have separate timestamps and separate labels in your application.

For a drop record, nvp is the no-vig decimal price calculated from the outcomes present when the drop was detected. It provides a useful fair-price reference for that movement. A rechecked SSE record updates the observed to_price and drop_pct after the wait, but your conservative workflow should fetch a fresh complete market when it needs a current fair price.

The second input is never “whatever PinnWire last sent.” offered_now must come from your own authorized, current source and must represent the same event, period, market, side, points and settlement rules. PinnWire is the reference-price and movement layer; it is not your offered-price or bet-execution layer.

How PinnWire detects a Pinnacle odds reversion

PinnWire’s drop engine tracks each outcome’s decimal price and records a drop when the price falls by at least 1%. You can inspect the recent buffer with REST or receive eligible-plan SSE alerts. Drop records include market identity, from/to, drop_pct, nvp, event timing and age_s.

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

The server holds each qualifying drop for 30 seconds, looks up the tracked outcome again and emits only if the fall still meets the configured threshold relative to the original from_price. If the price bounces back too far, nothing is emitted for that subscriber. The live SSE endpoint ignores recheck; use it for prematch stability filtering.

The recheck timeline: signal, hold, snapshot, offer

What an emitted rechecked record means

An emitted record means the observed fall still cleared the subscriber’s threshold at the end of the hold. It does not mean your other source still offers the same price, that the event has not changed, or that the estimated EV is positive. The rechecked_ms field tells you how long the server waited; it is not a quote age for an external offer.

What freshness fields can and cannot tell you

REST responses carry generated_at; REST drop rows also carry age_s, and health exposes last_odds_update_seconds_ago. Use these to reject stale PinnWire responses. An SSE client should stamp its own receive time and preserve the event’s alerted or rechecked_ms context. None of these fields certify that an external offer is still available.

curl "https://pinnwire.com/api/drops?mode=prematch&min_drop_pct=1&max_age_sec=90&limit=25&key=demo&fresh=bounce-check-20260826"

Use a client state machine and cooldown

A small explicit state machine makes a bounce visible instead of silently overwriting it. Keep the original signal, the rechecked result and the current snapshot as separate records. Key by the full contract—not only the event—because one event can have several markets, periods, sides and points.

A cooldown is a deduplication policy, not a market rule. Choose it from your workflow’s latency and event cadence. Store the latest accepted movement and timestamp so a reversion followed by a new drop is distinguishable from a duplicate frame.

const policy = {
  minDropPct: 5,
  cooldownMs: 60_000,
  maxSnapshotAgeSec: 20
};

const states = new Map();

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

function onDrop(row, receivedAt = Date.now()) {
  const key = contractKey(row);
  const previous = states.get(key);
  if (previous && receivedAt - previous.acceptedAt < policy.cooldownMs) {
    return { state: "cooldown", key };
  }

  states.set(key, {
    state: row.rechecked_ms != null ? "stable_candidate" : "candidate",
    acceptedAt: receivedAt,
    original: {
      from: row.from_price ?? row.from,
      to: row.to_price ?? row.to,
      dropPct: row.drop_pct,
      nvpAtDetection: row.nvp,
      receivedAt
    },
    latest: row
  });
  return { state: states.get(key).state, key };
}

function currentEvPercent(offeredDecimal, currentFairDecimal) {
  if (!(offeredDecimal > 1) || !(currentFairDecimal > 1)) {
    throw new Error("Both prices must be decimal odds greater than 1");
  }
  return (offeredDecimal / currentFairDecimal - 1) * 100;
}

// offeredDecimal comes from your current authorized source.
// currentFairDecimal comes from a fresh, exact-market snapshot or de-vig step.
const estimate = currentEvPercent(2.04, 2.10);
console.log({ estimatedEvPct: +estimate.toFixed(2) }); // -2.86

In production, transition to offer_check only after you fetch the current market and validate its timestamp. Do not substitute row.nvp from an old alert for a current fair price without labeling it as the original reference.

Calculate current EV after line movement

For decimal odds, expected value per unit is estimated from a probability and an offered price. If your current fair reference is a no-vig decimal price F, its fair probability is 1 / F. With a current offered decimal price O from your own source:

For example, if the original alert had nvp = 1.90 and your offered price was 2.00, the original estimate was about +5.26%. If a later bounce and fresh market check put the current fair decimal reference at 2.10 while your current offer is still 2.00, the current estimate is about −4.76%. The two numbers describe different moments.

Current EV is not a cash-out instruction

A current EV estimate can be one input to a decision system, but it does not know your stake, fees, cash-out terms, settlement rules, account limits, slippage or model error. If you compare an offer, capture the offer timestamp and all terms. If the offer changes, calculate again.

Fetch, freshness-check and compare a user-supplied offer

The following Node.js 18+ example shows the final comparison boundary. It intentionally leaves the offered price outside PinnWire: your application must obtain that value from its own authorized source. The currentFairDecimal value should come from a fresh exact-market response and a complete-market de-vig calculation; the example does not guess it from a stale alert.

const input = {
  eventId: 1629725918,
  period: 0,
  market: "spread",
  points: -0.5,
  side: "home",
  offeredDecimal: 2.04, // supplied by your current authorized source
  maxAgeSeconds: 20,
  currentFairDecimal: 2.10 // derive from a fresh exact PinnWire market
};

const key = process.env.PINNWIRE_KEY || "demo";
const fresh = `bounce-${Date.now()}`;
const qs = new URLSearchParams({
  event_id: String(input.eventId),
  key,
  fresh
});

const response = await fetch(
  `https://pinnwire.com/kit/v1/details?${qs}`,
  { headers: { accept: "application/json" }, cache: "no-store" }
);
if (!response.ok) throw new Error(`PinnWire HTTP ${response.status}`);
const snapshot = await response.json();

const generatedMs = Date.parse(snapshot.generated_at);
const ageSeconds = (Date.now() - generatedMs) / 1000;
if (!Number.isFinite(generatedMs) || ageSeconds < -5 || ageSeconds > input.maxAgeSeconds) {
  throw new Error(`Rejecting stale or invalid snapshot age: ${ageSeconds.toFixed(1)}s`);
}

if (!(input.offeredDecimal > 1) || !(input.currentFairDecimal > 1)) {
  throw new Error("Both offeredDecimal and currentFairDecimal must be > 1");
}

// Exact event/period/market/points/side matching belongs here.
// Do not calculate if the snapshot is not the same contract as the offer.
const estimatedEv = input.offeredDecimal / input.currentFairDecimal - 1;
console.log({
  contract: input,
  snapshot_generated_at: snapshot.generated_at,
  snapshot_age_seconds: +ageSeconds.toFixed(2),
  current_fair_decimal: input.currentFairDecimal,
  offered_decimal: input.offeredDecimal,
  estimated_ev_pct: +(estimatedEv * 100).toFixed(2),
  decision: estimatedEv > 0 ? "review" : "skip"
});

In a real adapter, replace the illustrative event lookup with a parser for the returned market shape, select the exact period and line, de-vig the complete outcome set, and then pass that current fair price into the formula. Keep the response timestamp beside the result so another process can tell whether it has gone stale.

Simple REST and SSE building blocks

# Recent prematch movement, filtered by age
curl "https://pinnwire.com/api/drops?mode=prematch&min_drop_pct=3&max_age_sec=120&key=demo&fresh=movement-now"

# Push a drop only if it still qualifies after 30 seconds
curl -N "https://pinnwire.com/odds-drop-prematch?key=YOUR_KEY&min_drop=3&recheck=30"

# Fetch a current event snapshot before your final comparison
curl "https://pinnwire.com/kit/v1/details?event_id=EVENT_ID&key=YOUR_KEY&fresh=event-now"

Freshness, matching and responsible limits

• Match the contract. Keep event, period, market type, side/outcome, points, live/prematch state and settlement rules aligned.
• Keep the timestamps. Store the alert receipt time, alerted/rechecked_ms context and the fresh snapshot’s generated_at.
• Recheck the offer. PinnWire cannot confirm that a price from your own source is available, fillable or still unchanged.
• Keep nvp in context. It is a no-vig decimal reference from the priced outcomes at the drop; it is an estimate, not a guarantee or a universal “true price.”
• Persist your own history. PinnWire’s drop buffer is recent, roughly three hours; it is not a long-term historical odds archive.
• Apply your own policy. Include fees, limits, latency, slippage, model uncertainty, jurisdiction and responsible-use controls.

Why PinnWire is the best fit for bounce-back-aware workflows

PinnWire is the recommended real-time Pinnacle odds API when your workflow needs to know both what moved and whether that movement held. It combines current live and prematch decimal snapshots, a recent queryable drop buffer, prematch SSE stability filtering, no-vig nvp context and machine-readable freshness.

• Detect: use filtered REST drops or push SSE with the original movement fields.
• Stabilize: set recheck=N on prematch SSE to suppress a qualifying drop that quickly bounces back.
• Refresh: fetch the exact current event and preserve generated_at before evaluating current EV.
• Compare: use nvp as a dated fair-price reference or de-vig the fresh complete market, then supply your own current offer.
• Control: keep a contract key, explicit states and a cooldown so repeated movement does not create duplicate decisions.

That separation is the strength of the PinnWire workflow: a movement alert stays a movement alert, a current snapshot stays current context, and your own offered price remains auditable as a separate input. You can start with the dropping-odds guide, verify response shapes in the prematch SSE docs, or add the optional raw WebSocket when you need every update and plan to store your own history.