OpenClaw Booking Agent
A timing-critical Playwright browser automation system for a highly competitive booking window, wrapped in a Telegram-first conversational workflow.
View repositoryRace the release window
OnePA badminton slots open in a narrow nightly window, so the problem was never just “automate the browser.” The real challenge was turning a stressful, timing-sensitive process into a single Telegram command that could parse intent, wait safely for the release window, and hand the right job to a Playwright-driven browser session at exactly the right second.
The workflow begins with a conversational confirmation step so the bot can validate venue, date, time, and schedule mode before touching the browser. Underneath that chat surface, the system is built from Playwright, Telegram Bot API messaging, SingPass QR authentication, NETS checkout handling, Node.js orchestration, and the OpenClaw agent layer.
Clawdbot
bot
What powers the workflow
The project works because several technical pieces are composed tightly together rather than treated as separate scripts. Browser automation, conversational messaging, authentication hand-off, checkout completion, and long-running scheduling all need to line up.
Playwright
Runs the Chromium browser automation behind booking, slot selection, cart navigation, receipt retrieval, and the final booking flow.
Telegram Bot API
Provides the command surface, confirmation loop, status updates, QR prompts, and final operator-facing notifications.
SingPass QR
Bridges the government login step through a user-scanned QR flow instead of trying to automate credentials directly.
NETS Checkout
Completes the payment leg after slot capture so the workflow ends in a paid booking rather than an unfinished cart.
Node.js
Handles scheduling, environment configuration, command parsing, and the long-running orchestration around the nightly release window.
OpenClaw
Supplies the local agent layer and skills workflow that turns the automation into a conversational operator tool.
Clawdbot
bot
Scheduled orchestration, not blind polling
Schedule mode turns the interaction into an operator-assisted runbook. After confirmation, the agent waits until 21:55 for SingPass authentication, verifies the session at 21:58, switches to the target date tab at 21:59:59, and only then starts the slot-detection loop.
The commit history shows the focus on robustness here too: deferred browser launch, better cart-error handling, terminal-closure survival, and explicit handling for Mac sleep/wake made the flow practical for real use instead of just successful demos.
Browser-native slot capture
Once the release window hits, the automation stays focused on the highest-value transition: detect the newly available slots, click them immediately, and move straight into the booking cart. That capture loop runs inside Playwright’s browser context, and recent changes shifted it into a tighter browser-side orchestration rather than a looser external polling loop.
Ends with a confirmed paid booking
The system does not stop at slot discovery. It drives the flow through cart summary, payment submission, and final Telegram confirmation so the output is a completed booking with a proof-bearing confirmation state, not a partially automated hand-off.
Clawdbot
bot
Receipt retrieval and operator controls
The project also grew beyond the booking run itself. A dedicated receipt command fetches the latest transaction PDF through the same authenticated flow, and a clear-session command resets stale conversation history so the operator can recover cleanly between runs.
Those additions make the bot feel more like a maintained operations tool than a one-shot script: book, verify, retrieve the proof, reset the context when needed, and support newer operator features like court preference selection in the booking command.
Clawdbot
bot
Engineering choices shaped by failure modes
The most interesting part of the project is how the implementation evolved around timing, interruption handling, and operator trust. Instead of claiming magic, the repository shows a steady pattern of reducing latency and hardening the workflow against the specific ways a nightly booking job can go wrong.
Schedule mode became operationally safe
The schedule flow now starts early enough to warn the operator at 21:50, prompts SingPass at 21:55, and handles late wake-ups without silently stumbling into a missed booking window.
Slot capture moved into the browser
Recent changes replaced a slower polling path with a focused wait-and-click orchestration, keeping slot detection close to the DOM and reducing hand-off delay when the 10:00 PM release hits.
Long waits survive real-world interruptions
A dedicated SIGHUP handler keeps scheduled runs alive even if the terminal session that launched them disappears, which matters when a booking job sits idle for hours before the release window.
Mac sleep and wake are treated as failure modes
The automation now checks whether the system woke up too late and either resumes with a warning or exits cleanly with a clear “booking window missed” message instead of failing in a confusing way.


