Build an Odds-Monitoring Bot with PhotonOdds

Build a monitor, not an auto-bettor

A useful first integration records price observations and sends an alert for human review. It should not place wagers automatically. Begin with a narrow job: monitor known events, validate each response, save the records you receive, and make the alert explain what changed.

Use the documented REST contract rather than inferred endpoint names or fields. API response shapes describes the bulk, event, best-odds, history, and change-feed routes.

Choose the retrieval model

For periodic snapshots, request GET /api/v1/odds with the filters your job needs. For one known event and market, request GET /api/v1/events/{id}/odds/best; spread, total, and Asian-handicap requests require their documented line parameter.

For incremental monitoring, prefer GET /api/v1/odds/changes. Store the cursor only after the full response has been processed successfully. On restart, resume from that stored cursor rather than assuming the most recent snapshot is complete.

load saved cursor
request /api/v1/odds/changes?cursor=<saved cursor>
validate response against the published schema
write each observation idempotently
commit the next cursor after the batch succeeds
notify a human only when the rule and data checks both pass

Validate data before alerting

An alert rule should check event identity, market, period, outcome, observed time, and the price actually returned. Treat a missing field, stale local record, or malformed value as a reason to log and skip—not to guess.

An observation can be worth reviewing without being a recommendation to act. Include the route, cursor, received timestamp, observed timestamp, and raw identifiers in the alert so a reviewer can verify the current market independently. Freshness and latency explains why an observation time matters.

Handle capacity and failures

Send X-API-Key from a server-side secret. On 429, stop work for that key and honour Retry-After; do not assume a generic request quota or reset time. Use bounded retries, structured logs, and an idempotency key or unique event identifier when persisting observations.

Keep an explicit kill switch. If validation fails repeatedly, the cursor stops advancing, or a downstream notification service is unavailable, pause alerts and surface the failure to an operator. API authentication and rate limits covers the documented capacity headers and recovery pattern.

Test with recorded responses

Before connecting an alert channel, test parsing against documented examples and captured non-sensitive responses. Test restarts, duplicate change records, a 429, invalid JSON, and a delayed notification. A monitoring service is reliable when it fails visibly and can resume without silently losing or duplicating data.

Configure the integration in PhotonOdds

Create a scoped key in the Developer portal, then validate your implementation against the published API schema before enabling alerts.

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.