Reliability & Operations - Uptime, Status & Incident Response

OddsPapi is built for teams that trade on the feed, so reliability is a first-class concern. This page explains how the platform is designed to stay available, how to monitor it, and how to reach us when something goes wrong.

---

​

Live status & incident history

Real-time platform status, ongoing incidents, and historical uptime are published on our status page: Subscribe on the status page to be notified of incidents and scheduled maintenance.

---

​

Architecture for availability

The platform is designed so that no single failure should interrupt your data flow:

• WebSocket-first delivery — a persistent gateway streams updates with minimal latency, avoiding the overhead and gaps of REST polling.
• REST + WebSocket redundancy — REST snapshots and the realtime stream are independent paths to the same data. If the stream drops, REST keeps your state current.
• Resume & replay — after a brief disconnect, clients resume from their last cursor and replay missed updates without a full refresh. See Resume & Replay.
• Deterministic recovery — when replay isn’t possible, the gateway emits snapshot_required so clients rebuild state from a fast REST snapshot. Recovery is an explicit, designed path — not an error state.

---

​

Designed for trading-grade failover

Recovery is bounded and predictable rather than best-effort:

• The gateway buffers a replay window (resumeWindowMs) so short interruptions resume with no data loss.
• If your cursor falls outside that window, a single REST snapshot restores full state in one call.
• Bookmaker connectivity is surfaced explicitly via the staleOdds flag, so you always know when a price may no longer be current.

This means worst-case recovery is a fast, well-defined REST snapshot, not an open-ended outage. See Resume & Replay for the full recovery flow.

---

​

Monitoring & operational responsibility

OddsPapi gives you the signals to operate safely; your client should act on them:

• Track the staleOdds flag per bookmaker before trading on a price.
• Handle snapshot_required and reconnect logic (see the Resume & Replay template).
• Respect rate limits and WebSocket connection limits; contact support to raise limits for distributed systems.
• Watch the status page for platform-level incidents.

---

​

Support & incident response

When reporting an issue, include your apiKey group, affected channels or endpoints, timestamps (UTC), and any serverEpoch / entryId values — these let us trace your session quickly.