Insights
Why Electronic Scoreboards Need a Partner API
The score-entry step every tournament and league platform inherits from paper — and why it’s the last thing to modernise
In short: Every match-management platform on the market — Xporty, Vola, Playtomic, Padel2day, and dozens more — solves the same operational problems: booking, brackets, rankings, notifications, payment. They share one unsolved friction point: the score. After every match somebody has to type it in. In an Americano or Mexicano where matches last ten minutes, that means the player picking up the balls is expected to also pick up a phone before jogging to the next court — a workflow players routinely skip. In a league, the referee or desk operator waits for players who are still chatting on court. In both cases the platform is fully modern except for the last thirty seconds, which are the ones that decide whether the whole system feels good to use. An electronic scoreboard with a partner API removes that step entirely: the platform sends the match to the scoreboard, players score with the remotes they were going to use anyway, and the final score returns to the platform without anyone typing anything.
What actually happens after every match on today’s tournament platforms?
Look at the workflow every tournament, league and social-format platform inherits from paper:
- The match ends.
- Somebody with a phone or a clipboard writes the score down.
- Somebody opens the platform app.
- Somebody taps the match, enters the numbers, confirms.
- The platform’s bracket, ranking or league table updates.
Steps 2 to 4 look trivial. Thirty seconds each. Multiplied by an eight-court Americano with sixty rotations, that’s four hours of typing per event. And it does not happen at that pace, because none of the people doing it are actually assigned the job — the players do it as a favour, or the desk operator does it as an interruption, or nobody does it and the club owner reconstructs the day from memory the next morning.
Every one of these platforms is, structurally, a database. What they need is data. What they have is a data-entry loop that does not fit the shape of the sport.
Why is score entry the friction point that survives every UI redesign?
Because it sits at the boundary between the software and the physical court, and software cannot cross that boundary alone.
Three things break at that boundary, over and over, on every platform:
Latency is unmanaged. The platform does not know when the match ended. It waits for the human trigger. A match that ended fifteen minutes ago and a match that ended ten seconds ago look identical to the platform until someone submits — which means the bracket is always slightly behind reality, and the desk operator is always guessing how long the current queue really is.
Errors accumulate silently. Players occasionally submit the wrong score, either because they misremembered or because they mistapped. There is no independent record to check against, so the mistake surfaces days later, in a dispute over rankings, when nobody can reconstruct what actually happened.
Dropout is invisible. Some matches never get entered. The bracket stalls on that fixture. Nobody chases it because nobody owns the queue of “outstanding scores.” The platform has no way to distinguish “still playing” from “finished twenty minutes ago and forgotten.”
A great app cannot fix a workflow whose failure mode is the phone is in the bag. Solving that requires hardware.
Why is it worse for short formats like Mexicano, Americano, Rey de Pista and Mixin?
Short formats solve a different problem for the club: fill a court, mix players, no fixed draw, keep it social. They’re also the shape most club evenings actually take. Playtomic and its peers have made them fully bookable, and platforms like Padel2day have made them fully organisable. What’s left is running the rounds.
The tempo is the whole point of the format. A Mexicano round is ten minutes. The rotation is one minute. Players are already walking to the next court before they’ve caught their breath.
Now insert: pause on the court · find phone · unlock · open app · tap the match · enter score · confirm · release the court. That’s forty seconds of standing still per rotation, which extends every round by seven per cent and completely breaks the flow the format was designed for. Predictably: half the players skip it, one player becomes the reluctant scorekeeper for the entire session, and the club owner spends the last thirty minutes chasing outstanding scores from a table of tired players.
The workaround clubs actually use is a paper sheet and manual re-entry after the event. Which is an admission that the platform’s own score-entry UI is unusable at the sport’s real tempo.
Every one of these platforms would solve this if it could. It can’t, because the fix is not a form field.
Why is it worse for leagues with a desk operator?
League matches invert the problem. The players play a longer match, take their time, celebrate, sit down, chat. Meanwhile the desk operator or the referee is waiting for them to come back to the desk so the score can be captured and the next fixture released.
There is no way to hurry four people sitting on a bench with a drink after a hard match. And there is no way to keep the desk operator productive during that wait, because they cannot confirm the next fixture until they’ve closed this one. So every match on every court gains a variable-length tail that the schedule did not budget for, and the day slides.
The result is consistent lag between match end and platform update, which pushes court assignments back, which delays the next match, which cascades through the day. Clubs running a busy Saturday league accept this as a fact of nature. It is not.
A referee with a scoreboard connected to the platform closes the result the moment the players leave the court. The desk operator sees the fixture close on their own dashboard within seconds, and the next fixture is already released. The queue does not stall for social reasons.
What does a partner-API-connected scoreboard change?
The mechanics are simple; the workflow change is not.
- The tournament platform sends the match to the scoreboard: player names, format, court, any short-format rules that apply.
- The scoreboard displays the names and starts the match in the correct format.
- Players score with the remotes they were going to use anyway. Every score change is a wireless event.
- When the match ends, the final score is already in the platform’s database. The bracket, the ranking or the league table has updated without anyone opening the platform’s app.
Nobody typed anything. Nobody walked to a desk. No paper sheet exists.
The scoreboard is where the score physically lives during the match. Any other data flow adds a translation step. A partner API removes the translation step, which is the same argument that governs scoring as a service at the level of a single court: the score should not be re-entered anywhere, because every re-entry is a chance to be wrong.
What else does the tournament platform get once the scoreboard is connected?
The final score is the least of it. Once the scoreboard is speaking to the platform in real time, the platform gets a stream of point-level events that unlock things a form field cannot:
- Every point, timestamped. Not just the final score — game-by-game and point-by-point events. That is rankings data with rally-level context, and it is clip boundaries for streaming with no operator.
- Live match state during play. The platform can push the current score to spectators, to a TV at the bar, to WhatsApp share links, to overlay layers on a broadcast, without polling anything.
- Zero disputed submissions. The score was not typed. There is nothing to mis-key. Every point was seen and heard on court by four people the moment it was recorded — a socially verified score, not an asserted one.
- Rotation automation for short formats. In a Mexicano, the platform can trigger the next match on the scoreboard the moment the current one closes. Players walk to the next court and find their names already up.
- Auto-close on all courts simultaneously at end-of-round. No court is left “still open” waiting for someone to submit.
None of this is possible when the source of truth is a form field. All of it is straightforward when the source of truth is the scoreboard.
Score-entry paths, side by side
| Path from match end → platform database | Where the friction sits |
|---|---|
| Player picks up phone, opens platform app, taps match, enters score | Requires the player to interrupt the rotation; skipped often enough that the club falls back to paper |
| Referee enters score on their own device | Waits for the players to leave the court; blocks the queue |
| Desk operator enters score from a paper sheet | Batched; result lands in the platform ten to sixty minutes after the match |
| Camera-based inference | Requires per-court camera + display; scoring accuracy tolerance is zero (see Scoring as a Service) |
| Scoreboard + partner API | Zero human steps between match end and platform update |
Which tournament platforms already work this way?
Today, LedsCount ships a WebSocket partner API that any tournament, league or booking platform can connect to. The two live integrations at the time of writing are Xporty and Vola, both operational and used at real events across Spain and the Benelux. Additional partners are onboarded on a rolling basis; the integration is small on the partner side because the message set is small — start match, receive live score events, close match.
The WebSocket reference and interactive sandbox both live at app.ledscount.com/api-sandbox. That is one URL for two audiences: partner developers who want to see the message shape, and platform product managers who want to click through what the flow feels like without writing any code.
If you run a platform and want to be next: it’s typically a two-week engagement on the partner side, we ship you a loaner scoreboard for the duration, and you’re live for your next event.
FAQ
Isn’t a phone-based score-entry screen good enough? It’s good enough at the demo. It fails in the field for the same reason the on-court scoring apps do: the phone is in the bag, and asking players or referees to stop, retrieve it and tap a form after every match adds friction the platform has no way to absorb. At the sport’s real tempo — a Mexicano round is ten minutes — that friction rewrites the workflow. A partner-API scoreboard closes the loop without a phone in the picture.
What about voice input or chatbot score entry? They move the same friction to a different modality. The player still has to initiate the interaction, still has to confirm four numbers, still has to catch and fix errors. And they add noise on a court that has three other matches around it. The score already exists on the scoreboard the moment the point ends; anything that re-reads it is adding a translation step, not removing one.
Do partners have to pay for the LedsCount partner API? No. The API is open to any tournament, league or booking platform whose users have LedsCount scoreboards on court. The commercial relationship is between LedsCount and the club that owns the hardware; the partner integrates for free and gets a loaner scoreboard for the duration of the integration work.
What if our platform uses a scoring format the scoreboard does not know? The scoreboard supports all major international padel, tennis and pickleball formats, including short-format variants (Americano, Mexicano, Rey de Pista, Mixin) and the current FIP formats. If your platform runs something more exotic, the format lives in the partner-API message and the scoreboard follows it — the display logic is data-driven, not compiled in.
Can the scoreboard work without a partner integration? Yes. The scoreboard is fully useful standalone — players score with the remotes and see the score on court. The partner API is what closes the loop back into the tournament platform, so the result lands in the bracket, ranking or league table without anyone typing. Clubs adopt the scoreboard first and turn on partner integrations one platform at a time.
How long does a partner integration take? Two weeks on the partner side is typical, because the API surface is small: start a match, receive live score events, close the match. LedsCount ships a loaner scoreboard for the integration period and the WebSocket reference plus interactive sandbox lives at app.ledscount.com/api-sandbox.
LedsCount builds LED scoreboards for padel, tennis and pickleball, and the partner API that lets tournament and league platforms close matches without anyone typing. Get in touch if you run a platform or a club and want to see the loop close.