I Built a Pickleball API. Here Are 7 Things You Could Build With It 🏓

John Sitherstone — Sun, 26 Jul 2026 09:01:38 +0000

I’ve been building pickleball-api.com, an API for developers who want to build with professional pickleball data.

Why?

Because I wanted to build things with pickleball data myself — and discovered that getting clean, structured, application-ready data was harder than it should be.

There’s plenty of pickleball information on the web. But there’s a big difference between information you can look at and data you can build software with.

So I started building the API I wanted to exist.

And while working on it, I started thinking about a more interesting question:

What could developers actually build if pickleball data was easy to access?

Here are seven ideas.

1) A live scores app

The obvious one.

Instead of building and maintaining the whole data collection layer yourself, you could focus on the actual product: a web or mobile interface showing matches, scores and tournament progress.

The interesting engineering problems then become things like caching, polling, state updates and designing a UI that makes a tournament easy to follow.

You could keep it simple with a live scoreboard, or build towards a full pickleball equivalent of the sports apps people already use for football, tennis or F1.

2) A pickleball stats dashboard

Once you have structured match and player data, you can start asking questions.

Which players are in the best form?

How do results change over time?

Which matchups produce surprising results?

You could build a dashboard using React, Vue, Svelte or whatever else you fancy, add a charting library, and turn the API into an interactive way of exploring the professional game.

This is probably one of the projects I’d recommend if you’re learning frontend development: real data makes a dashboard much more interesting than another demo populated with Lorem ipsum.

3) Player comparison tools

Pick two players and compare them.

It’s a simple concept, but there are lots of directions you could take it.

Career results. Recent form. Head-to-head records. Tournament performance. Rankings.

You could even generate shareable comparison pages:

Player A vs Player B: who has the better record?

That starts to become useful not just as a coding project, but as something fans might actually use.

4) A fantasy pickleball game

This is where things get more ambitious.

If you have players, tournaments and results as structured data, you have the foundations for fantasy pickleball.

Let users choose a roster, award points based on real-world performance and run leagues between friends.

Suddenly the interesting problem isn’t accessing the sports data. It’s designing scoring systems, authentication, leaderboards, scheduled jobs and all the other infrastructure around the game.

Someone please build this.

I’d play it.

5) An AI pickleball assistant

LLMs are much more useful when they have access to relevant structured data.

Instead of asking a model:

Who is playing well at the moment?

and hoping its training data happens to know, you could let an AI application query current pickleball data and use the model to interpret it.

For example:

Show me Anna Bright’s recent results.

Compare these two players.

Summarise what happened in this tournament.

The API provides the facts; the LLM provides the interface and explanation.

That combination — structured data + natural language — is one of the areas I’m most interested in experimenting with.

6) Tournament notifications

Not every project needs a giant frontend.

You could build a small service that watches for changes and sends notifications when something interesting happens.

A favourite player starts a match.

A result comes in.

A tournament reaches a particular round.

That could mean push notifications, email, Discord, Slack, Telegram — whatever you want.

It’s also a nice project for experimenting with scheduled jobs, event-driven architecture and storing user preferences.

7) Build something I haven’t thought of

This is the reason I wanted to build an API rather than just another pickleball website.

An API doesn’t decide what the final product should be.

Developers do.

Maybe it’s a data visualisation.

Maybe it’s a prediction model.

Maybe it’s a Discord bot that posts tournament results.

Maybe it’s a completely unnecessary Raspberry Pi scoreboard sitting on your desk.

Those are often the most interesting projects.

Why I’m building this in public

Pickleball API is still something I’m actively building.

That means there are technical decisions to make, data problems to solve, infrastructure to improve and almost certainly things I’ll discover I’ve built badly.

So rather than only writing about it once everything is polished, I’m going to document some of that process here.

I’m planning to write about the architecture behind the API, collecting and normalising sports data, infrastructure, API design, things that break, and what I learn trying to turn a side project into a useful developer product.

And if you build something with the API, I’d genuinely like to see it.

Especially the Raspberry Pi scoreboard.

⸻

pickleball-api.com — professional pickleball data for developers.

api #webdev #javascript #buildinpublic

DEV Community: John Sitherstone

I Built a Pickleball API. Here Are 7 Things You Could Build With It 🏓

api #webdev #javascript #buildinpublic