From login to a booked unit in seconds: the architecture of our Sakani (sakani.sa) booking companion

Sakani is Saudi Arabia’s national housing portal: projects, land plots, ready units and financing support — and with it, rare moments when new units are released and vanish within minutes. A family that has waited years for its plot wants one thing: not to miss that moment. This is the story of SakaniBot, a system Smart Lead Tech built to watch units and carry out the reservation steps on behalf of an authenticated user, from login to a confirmed booking.

Principle one: the human owns the identity, the system owns the speed

The system stores no password and impersonates nobody. The user logs into Sakani from their own browser, receives the one-time code (OTP) on their mobile and types it themselves. What the system does next is the boring part humans are bad at under pressure: continuous monitoring, an exact sequence of steps, and execution in the right second.

The rule we held to: every session starts with a human proving their identity on the official platform. Automation starts after that, never before.

The architecture: five services, one job

1. Chrome extension (the interface): runs inside the user’s browser on sakani.sa. After login and the mobile code, it captures the authenticated session and the reCAPTCHA token, sends them securely to the booking engine, and shows live booking status in a UI themed per the user’s dashboard account.
2. Booking engine (FastAPI — Python): receives the session, manages a session pool with a TTL, and executes the reservation sequence step by step with a circuit breaker and an error classifier that tells “unit taken by someone else” apart from “transient outage”.
3. Projects monitor (Python): scans the projects and units the user selected in the dashboard, detecting the moment a new unit appears or a cancelled one returns.
4. Dashboard (Laravel + Filament): users, subscriptions, per-user monitored projects, notification templates and booking analytics. It syncs its configuration to the monitor every 60 seconds over a signed API.
5. Telegram notifier: routes notifications to each user’s own channel: “unit available now in project X”, “booking started”, “booked — reference number …”.

The complete booking journey, step by step

1) Login and the one-time code

The user opens Sakani, logs in, enters the mobile code. The extension waits until the session is valid and then captures it. We ask nothing they would not have done themselves.

2) Eligibility check

Before any attempt, the engine asks the platform: is this user eligible for this project? An ineligible beneficiary wastes neither their time nor the platform’s.

3) Precondition and booking token

Reserving a unit on Sakani is not one request; it is a sequence: request a precondition, wait for a booking token issued by the platform, then submit the reservation with that token inside a short window. The engine drives this sequence with precise timeouts and measured retries, logging every step.

4) Submission and confirmation

On success the reference number is read and sent immediately to the user on Telegram and to the dashboard. If the request is rejected because the unit was taken, the engine returns to monitoring automatically instead of failing silently.

5) After the booking

The user completes the official procedures on Sakani themselves (documents, financing, contract). The system’s role ends at the confirmed reservation; we touch no legal or financial step.

What actually made the difference

• Error classification: half the “failures” in early versions were transient blips. Once we separated terminal from temporary errors, successful bookings rose noticeably without any increase in request volume.
• Session pool: a pre-warmed session with a TTL means the moment of availability is not lost in a handshake.
• Notifications that explain: “Unit 214 — project X — 3 bedrooms — booking started” beats “alert”. The user understands and trusts.
• A mock environment: a server that simulates the Sakani interface so the whole sequence can be tested without touching the real platform — which is what made development safe and responsible.

The impact

Families using the system no longer stayed up refreshing the page. Notifications arrived in the first seconds of availability, and reservations completed in moments that used to be lost to natural manual delay. Most importantly: every booking was made under its owner’s identity and mobile code, with no shortcuts.

For anyone considering similar automation

1. Respect the platform you build on: real authentication, real eligibility, sensible request limits.
2. Make the sequence observable: a log for every step, a metric for every failure reason.
3. Build the simulator first, then the engine.
4. The notification is part of the product, not an add-on.

At Smart Lead Tech we build real-time monitoring and booking systems for property, travel, and government and private services — with the same philosophy: the human authenticates and decides, the system watches and executes at the right time.