Heartbeat Callback

Usage Notes

• Enable HEART_BEAT to receive regular heartbeat callbacks for health monitoring.
• If HEART_BEAT is set to 0, no heartbeat messages will be sent.
• Adjust HEART_BEAT_INTERVAL based on your monitoring requirements (recommended: 10–30 seconds).
• Heartbeats can be used to detect connection loss or SDK downtime and trigger alerts or recovery processes.

Important Notes for SDK Integration

• Resubscription Required After SDK Restart:

  If the SDK restarts, or a connect: true payload is received in the Connection Callback, all previously subscribed markets must be subscribed again. Ensure your application handles re-subscription automatically to maintain real-time updates.

• Closed Markets After SDK Restart:

  If the SDK restarts, any markets that were previously closed or inactive will not be included in the market list initially. Your application should handle this scenario and fetch updates as markets become available again.

• Market ID Availability for Results:

  When the SDK starts, it does not have the complete list of markets whose results were declared before startup. The SDK will only receive result updates for markets after it has started.

  To fetch results for markets that were closed or declared prior to SDK startup, you must call the Result by Event API (/events/result?eid) after the SDK is running.

Conclusion

This document serves as a comprehensive technical reference for integrating and operating with the SDK platform. It includes:

•  REST APIs for sports, events, markets, results, and subscriptions
•  Real-time callback responses for 12+ market types (e.g., BM, F2, BB, OE, MT, KD, OE, Betfair)
•  First-time installation and execution guidance for Linux, Windows, and Docker
•  Full glossary mapping for API responses and live data formats

Each API and callback response is designed with short, optimized keys to ensure performance. This guide helps decode, interpret, and integrate those structures with ease.

Keep This Document Updated

As the SDK evolves, we recommend updating this doc alongside:

• New APIs or callback types
• Changes in response structure or naming conventions
• Version upgrades (SDK or endpoints)
• New sports or market types being introduced  

Best Practices

1. Validate Odds Timestamp
   • Always check that the last odds timestamp is greater than the current odds timestamp.
   • Only accept the odds update if it’s newer; otherwise, reject outdated odds to prevent stale data from being processed.
2. Handle SDK Disconnection
   • If you receive connect: false in the callback, suspend all markets on your side.
   • Resume operations only after connect: true is received, ensuring all markets are re-subscribed.
3. Betfair Market Update Interval
   • Betfair market data for fancy markets will be provided at 4-second and 10-second intervals, even if odds remain unchanged.
   • Use the timestamp to confirm freshness of the data.
4. Prefer WebSocket Over Callback URL
   • We recommend using WebSocket for real-time odds and event updates.
   • WebSocket offers faster response, low latency, and efficient continuous data streaming.
5. Use Internal Callback URLs
   • If using a callback URL, ensure it is internal (private) and not exposed publicly.
   • This improves security and performance, reducing risk of external access or throttling.
6. Distribute Odds via WebSocket
   • You should distribute odds through your own WebSocket on the website or application.
   • This ensures real-time synchronization and a smooth user experience with minimal delay.

Document Meta Info