PhotonOdds API: Polling, Changes, and WebSockets

Start with the data you actually need

PhotonOdds supports REST retrieval and a REST change feed. WebSocket access may be available to eligible API plans; check the current API documentation and your plan before designing around it. Outbound webhooks are not part of the public API contract described here.

The sensible starting point is usually the least complex transport that meets your data requirement. A faster delivery method improves freshness; it does not make a price actionable or suitable by itself.

Scheduled REST polling

Polling means requesting a current snapshot on a schedule. For example, a service can request GET /api/v1/odds for a selected set of events, persist the result, then run again later.

Polling is a good fit when:

• your application needs periodic snapshots rather than every update;
• the set of events is small and known;
• you want simple retry and deployment behaviour; or
• you are building an analysis or reporting job.

Use a schedule that respects the capacity reported for the API key. Do not hard-code a generic request rate: limits are tier-specific and exposed in response headers.

REST change feed

If repeatedly retrieving an unchanged snapshot would be wasteful, use GET /api/v1/odds/changes. The endpoint returns changes after an optional cursor and can be filtered by sport, bookmaker, event, or market.

A robust consumer:

1. stores the last successfully processed cursor;
2. requests the next change page with that cursor;
3. processes each change idempotently; and
4. saves the new cursor only after the batch succeeds.

This model keeps recovery straightforward: after a restart, continue from the last saved cursor rather than assuming no updates occurred.

WebSocket access

WebSockets are useful only when your API plan is entitled to them and your application can safely maintain a long-lived connection. They add responsibilities that a REST job does not have: reconnecting after a drop, resynchronising state, handling backpressure, and checking plan access.

Use WebSockets only after confirming the entitlement and connection contract in the current documentation. Keep a REST reconciliation path so a reconnect does not leave your local state incomplete.

Pick for reliability, then verify the price

Requirement	Prefer
Periodic reporting or small, known scope	Scheduled REST polling
Incremental updates with restart-safe recovery	/odds/changes
Entitled, persistent real-time consumer	WebSocket plus REST reconciliation

Whichever route you choose, log response times, cursors, errors, and the provider's observed_at values. A data update is a record to evaluate, not a bet instruction. API response shapes and API authentication and rate limits cover the companion implementation details.

Configure this in PhotonOdds

Use the Developer portal to create a scoped API key, then validate an integration against the published API schema before it handles live data.

18+ only. Betting carries risk. PhotonOdds provides analytical and educational tools, not a promise of profit or a recommendation to place a bet. If gambling is causing harm, see Responsible Gambling.