REST Polling
Fetch the latest match state on demand. Simple to implement, works everywhere.
WebSockets
Receive updates instantly via Pusher. No polling, no delays.
Prerequisites
Before you begin, make sure you have:- A Padel API account (sign up here)
- An API token from your API Tokens page
Step 1: Find Live Matches
First, discover which matches are currently being played:status: "live". Each match includes its id, which you’ll use in the next steps.
Step 2: Get the Live Match State
Once you have a match ID, fetch its point-by-point data:Response structure
Field reference
| Field | Description |
|---|---|
status | Match status: live, finished, scheduled, etc. |
coverage | Data completeness: tracking (collecting data), full (all games tracked), partial (some gaps), or null (no data) |
channel | Pusher channel name for real-time updates |
sets[].set_number | Set number (1, 2, or 3) |
sets[].set_score | Final set score (e.g. "6-2") when complete, null while in progress |
sets[].games[].game_number | Game number within the set |
sets[].games[].game_score | Cumulative set score before this game started (e.g. "3 - 1") |
sets[].games[].points | Array of point scores during the game (format "team1:team2") |
Step 3: Subscribe to Real-Time Updates
Instead of polling the REST endpoint repeatedly, subscribe to WebSocket updates for instant notifications on every point.Connection details
| Parameter | Value |
|---|---|
| Provider | Pusher |
| App Key | 0ffbefeb945e4e466065 |
| Cluster | eu |
| Channel format | matches.{matchId} |
| Event name | App\PadelApi\Events\MatchLiveUpdated |
Channels are public — no authentication handshake is required to subscribe. You only need the Pusher app key and cluster.
Install a Pusher client
Subscribe to a match channel
id, self, status, coverage, channel, sets, and connections.
Step 4: Handle Match Completion
When a match ends, thestatus field changes to finished. Use this to clean up your subscription:
Recommended Workflow
- Find live matches —
GET /api/live - Get initial state —
GET /api/matches/{id}/live - Subscribe to updates — Connect to Pusher channel
matches.{id} - Detect match end — When
statuschanges tofinished, unsubscribe from the channel
Tips
REST polling vs WebSockets — when to use which
REST polling vs WebSockets — when to use which
Use REST polling when you need a simple integration, are building server-side batch processes, or your environment doesn’t support persistent connections. Use WebSockets for user-facing applications where latency matters — live scoreboards, mobile apps, or real-time dashboards.
Not all matches have live data
Not all matches have live data
The
coverage field indicates whether any points were lost during tracking. full means every point was captured, partial means some points were missed due to source feed gaps, and tracking means the match is live and data is being collected. Check this field before relying on point-level completeness.Handling reconnections
Handling reconnections
Pusher clients handle reconnections automatically. If the connection drops, the client will reconnect and resubscribe to channels. However, you may miss events during the disconnection — fetch the latest state from the REST endpoint after reconnecting to fill any gaps.
Rate limits for the REST endpoint
Rate limits for the REST endpoint
If you choose REST polling over WebSockets, avoid polling more frequently than once every 10 seconds per match. For lower latency, use WebSockets instead.