How the two transports work
The REST API is a classic request-response model: your app asks for data (a fixture, a player profile, a set of pre-match odds), the server responds once, and the connection closes. The WebSocket API instead opens a single persistent connection, and the server pushes updates to your app as they happen - no repeated requests required.
When REST is the right choice
- Fixtures and schedules - a list of upcoming matches doesn't need a live connection.
- Player profiles and rankings - stable data that changes infrequently.
- Historical results and H2H records - static once a match is finished.
- Standings - useful to refresh periodically, not on every point.
- Pre-match odds - set ahead of a match, so a live connection isn't necessary.
REST is simpler to implement, easier to cache, and fits naturally into a typical page-load or cron-job pattern.
When WebSocket is the right choice
- Live score widgets that need to update the moment a point is won.
- Live (in-play) odds that need to stay in sync with the score as a match progresses - a different feed from pre-match odds above.
- Push notifications for match start, set changes, or match point.
- Any product where polling would be too slow or too expensive - a WebSocket connection avoids the trade-off between "poll often and waste requests" and "poll rarely and show stale data".
A common pattern: use both
Most production apps use REST and WebSocket together: REST to load the initial state (today's fixtures, current standings) when a page loads, and WebSocket to keep that state fresh while the user has the page open. For example, a live score widget might call the REST fixtures endpoint on page load, then open a WebSocket connection scoped to the matches currently in progress to receive point-by-point updates.
Implementation notes
A WebSocket client needs to handle reconnects (mobile networks drop connections routinely) and should treat the REST response as the source of truth on first load, then apply WebSocket messages as incremental updates on top of it. See our performance and reliability guide for more on designing around real-world network conditions.
Getting started
If you haven't made your first request yet, start with REST - it's the fastest way to see the shape of the data. Follow Getting Started With the Tennis API in 5 Minutes, then add the WebSocket feed once you know which parts of your product actually need live updates.