How I reverse-engineered Playtomic's mobile payment API to build a padel court booking bot

Hadriel — Sat, 16 May 2026 17:37:56 +0000

Hey Dev.to community 👋

I'm Hadriel, a 25yo solo founder building Padel Snipe from Bordeaux, France. Today I want to share how I reverse-engineered Playtomic's mobile payment API to build a padel court booking automation.

If you're into reverse engineering, anti-bot strategies, or just curious how booking automation works in practice, this should be interesting.

The problem

Padel (a racket sport huge in Spain and growing fast in France) has a booking problem. At popular clubs like PADEL 15 in Bordeaux, courts get fully booked within 30 seconds of opening on Playtomic, the dominant European booking platform.

I wanted to build a bot that monitors slot openings and books at the millisecond a court becomes available. Sounds simple. It wasn't.

The first wall: Playtomic uses Next.js Server Actions

My first approach was the classic one: intercept the booking calls in the browser using Chrome DevTools, replay them via HTTP.

It didn't work.

Playtomic's web app uses Next.js 13+ Server Actions for the payment flow. The actual payment logic runs on their server, not in the browser. The browser just sends a serialized action call, and the server responds with a redirect or error.

You can't intercept what doesn't exist client-side.

The pivot: capturing the mobile app

I switched strategy: capture the mobile app's API calls instead. The mobile app is a thin client that calls REST endpoints directly.

Setup:

iPhone with Playtomic installed
Windows PC running mitmproxy
iPhone proxied through the PC's IP
mitmproxy CA cert installed on iPhone

I made a real booking through the app, captured everything, and analyzed the flow.

The 4-step payment flow

After analyzing the captured traffic, the payment flow turned out to be exactly 4 sequential calls:

// Step 1: Create payment intent
POST /v1/payment_intents
{
  match_id: "uuid",
  amount: 2000  // cents
}
// → returns payment_intent_id

// Step 2: Select payment method (prefer CREDIT_CARD)
POST /v1/payment_intents/{id}/payment_method
{
  payment_method_type: "CREDIT_CARD"
}

// Step 3: Update match registrations
PATCH /v1/matches/{match_id}/registrations
{
  registrations: [
    { user_id: "me", pay_now: true },
    { user_id: "guest1", pay_now: false },
    { user_id: "guest2", pay_now: false },
    { user_id: "guest3", pay_now: false }
  ]
}

// Step 4: Confirm (empty body!)
POST /v1/payment_intents/{id}/confirm
{}

The empty body on step 4 was the surprise. I lost an hour debugging "why does my POST return 400" before realizing the API expects exactly {}.

Detecting when clubs open their booking windows

Once I could book, I needed to know when to book. Each club has its own opening rule:

Some open J-7 at 8am (the "classic" pattern)
Some open J-5 at the exact mirror hour of the slot (PADEL 15 does this)
Some have weird custom rules

I built a 3-phase detection system:

Manual user input — when a user adds a club, they can specify the rule if they know it
Crowdsourced votes — users see the proposed rule and can confirm or dispute
Binary dichotomic scan — a worker probes the API to find the exact opening time, narrowing to 15 minutes precision

The dichotomic scan was the most fun to write. Given a target date, the worker queries the availability endpoint with different days_ahead values, watches when the slot first appears, then does a binary search on the time-of-day to find the exact opening moment.

The worker architecture

I used BullMQ on Railway with Upstash Redis (Ireland region for low latency to Playtomic's EU servers).

Key learnings:

Don't hold concurrency slots while waiting: a snipe waiting for an opening shouldn't block 1 of 10 worker slots. Use delayed re-enqueue (+5min) instead.
Sanitize job IDs: BullMQ silently fails when job IDs contain colons. I lost 3 hours to this. Added sanitizeJobId() helper everywhere.
Rate limit handler: 429 responses need exponential backoff separate from retry count, otherwise you blow through retries on temporary rate limits.

The first successful production snipe

After 6 months of building, my first production snipe succeeded last Tuesday at 17:31:20 UTC. PADEL 15 Bordeaux, Sunday 17:30 slot. Reaction time: 18,702 milliseconds after slot opening.

The reservation held until I cancelled it myself 4 days later (couldn't find partners 😅).

The full stack

For the curious:

Monorepo: Turborepo
Web app: Next.js 15, TypeScript, Tailwind, shadcn/ui
Worker: BullMQ on Railway
Database: Supabase (Postgres + Auth + Storage)
Redis: Upstash (Ireland)
Payments: Stripe (live mode)
Emails: Resend
Notifications: Telegram bot
Reverse engineering: mitmproxy + iPhone

What I'm working on next

Anti-detection layer: UA rotation, jitter, sticky proxies per userId (waiting for ~30 simultaneous users before activating)
Pattern learner: using captured observations to predict opening times per club within 15-minute windows
B2B2C: clubs can co-brand a landing page and earn commission on referred users

Try it

If you play padel in France, UK, or Spain, you can try Padel Snipe for free at padelsnipe.com. FREE plan includes real-time alerts, PRO (14€/month) adds auto-booking, ELITE (29€/month) adds priority booking.

I'm also documenting the full build journey on Building Padel Snipe — weekly newsletter with technical decisions, real data drops, and honest growth metrics.

Happy to answer questions about any part of the stack or the reverse engineering process. Especially curious if anyone here has shipped similar millisecond-precision automation against booking platforms — would love to swap notes on anti-bot strategies.

Cheers from Bordeaux 🇫🇷

DEV Community: Hadriel