Find the slot before it is gone

We watch the visa appointment portals 24/7, so a cancellation that lives nine seconds does not slip past.

Smot Visa Slots  ·  slot-scarcity engine

A visa slot lives for nine seconds. Nobody wins that by refreshing.

Appointment slots at VFS Global open at random hours and are gone in 3–15 seconds at peak season. This watches them 24/7 and puts an alert on the operator's phone — naming the clients who are waiting for that exact date.

The bot watches. A human books.
3–15sSlot lifespan at peak season
87%Peak slots a fixed 60s poll misses
23Schengen countries on one checker
₹440One-time proxy credit, free-tier VPS
01

The bottleneck is a race a human cannot win

A small agency does ~25 bookings a month, all by hand. Clients are asking for Italy Schengen. The slots exist — they just don't wait.

Batch release

Once or twice a month

Next month's calendar opens on the 1st–5th, in early embassy hours. Many slots at once, gone in minutes.

Cancellations

Daily, at random, 24/7

One slot, no warning, alive for 3–30 seconds. This is where most bookings actually come from — and where manual watching fails completely.

The human limit

Attention doesn't scale

One operator can watch one tab. Twenty-five clients across multiple countries and cities is not a refresh problem, it's an arithmetic one.

02

The one rule

Everything in the design follows from this, and it is permanent — not a feature waiting to be built.

The bot watches.
A human books.
There is no auto-booking.

Not a phase · not a stretch goal · no column in the schema

Auto-booking is not risky for us. It is risky for the client — and the client has already paid. A Schengen applicant is ~₹8,600 in before a slot is visible; a US applicant is ~₹16,000 in MRV fees. The US Embassy in India has cancelled 2,000+ bot-booked appointments, suspended the accounts' scheduling privileges, and named agents and fixers as the target of a zero-tolerance policy. That downside lands on the customer, not the agency.

Watching — what this doesAuto-booking — what it never does
Account usedOne dummy watcher accountThe client's own account
Actions takenRead-only calendar pollsWrites: hold, submit, pay
Worst caseDummy account flagged — make anotherAppointment cancelled, fees gone, scheduling suspended
Who absorbs itUsThe client who paid us
The asymmetry is the whole argument. A watcher's failure mode costs a throwaway email; a booker's failure mode costs a paying customer their appointment.

This is why it is sellable to other agencies. An agency buying a booking bot is buying a liability it cannot insure. An agency buying an alerting bot is buying reaction time, and keeps the human judgement — and the accountability — where it already sits. Client credentials are never stored. The database has no column for them and will not grow one.

03

What actually happens

Five parts. A watch target goes in from Telegram; an alert with names on it comes back out.

Telegramoperator Scheduleradaptive interval Checkerone per provider VFS calendarJSON endpoint SQLitetargets · clients · slot log session + proxywarm, geo-matched /watch poll due target ~2 KB GET slot found → matched to waiting clients → alert in <60s human books manually, on the portal
The dashed boxes are what keeps it cheap and unbanned: a session warmed on a timer rather than at slot time, and a proxy whose country matches the account's.
What lands on the phone
🚨 ITALY Schengen — Mumbai Dates: Aug 20, Aug 21 👥 Waiting: Marco R. (1), Sneha P. (3) 🔗 open booking page

The client join is what makes it usable at 25 bookings a month. The operator doesn't decide whether the slot matters — the alert already says who it's for.

Captchas

₹0, by routing around the problem

Captchas only fire at login, and login is rare by design — one to three a day. The screenshot goes to the operator on Telegram, who types the answer back. No solver subscription.

04

Checkers are keyed by provider, not by country

This is the whole thesis. Embassies outsource appointments to a handful of companies, so the unit of work is the company — not the flag. Build Italy, and Europe is nearly built.

BaseChecker warm_session · poll vfs_global.py one module, written once AustriaBelgiumCroatia Czech RepublicDenmarkEstonia FinlandGermanyGreece Hungary Italy  ← phase 1 LatviaLithuaniaMalta NetherlandsNorwayPoland PortugalSlovakiaSlovenia Spain *SwedenSwitzerland 23 countries · 0 extra modules · 1 database row each tlscontact.py France · ~1 day bls.py Spain · ~1 day ais.py USA · ~2 days
Adding Germany after Italy is one row in watch_targets, not a new module. A minority of VFS countries run older custom portals and need a per-country override hook — budget half a day each, not a rewrite. * Spain routes to VFS in some jurisdictions and BLS in others; confirm per city.
05

Why it can afford to run forever

Two design decisions do most of the work: poll faster only when it matters, and never put the fast path behind a browser.

45s · normal ±20% jitter — periodicity is a bot signature 12s · batch window 1st–5th of month, 08:00–13:00 embassy hours HIT 30 min cooldown — operator is booking stop burning bandwidth on a target already won 45s
A fixed 60-second poll misses roughly 87% of peak-season slots. The burst is not "poll harder" — it is poll harder only in the five-hour windows where batches actually drop, which keeps both cost and ban risk down the rest of the month.
warm_session() · Playwright heavy · rare · every ~25 min · megabytes images, fonts and CSS blocked → 5× lighter login poll() · httpx light · constant · every ~45s · kilobytes provider's own calendar JSON, no page render hands over a warm session MONTHLY PROXY BILL full page load per check → ~2 MB → ₹15,000/mo JSON poll per check → ~100 KB → ~₹750/mo same information, ~20× less bandwidth Actual run cost today: ₹440 one-time proxy credit plus a free VPS. Months of runtime for pizza money.
Residential proxies bill per gigabyte, so every byte is money. Profiling recently found the login was the real bandwidth hog rather than the polling — blocking images, fonts and CSS cut it roughly fivefold.

Anti-ban discipline, treated as non-negotiable

  • Geo-matched proxies. An India-registered account logging in from Frankfurt is the clearest bot signal there is. The proxy country always matches the account's.
  • Jitter on every interval. ±20% randomisation — perfectly periodic requests are themselves a signature.
  • Log in rarely, reuse the session. Sessions are re-warmed on a timer, never on demand: re-warming at slot time means missing the slot.
  • One dummy watcher account per provider. Client accounts are never touched by code, and their credentials are never stored.
  • Exponential backoff on errors, capped at ten minutes. A failing target goes quiet instead of hammering.
06

Where this goes

Phase 1 is deliberately the hardest scraper on the list. VFS runs Cloudflare, DataDome and a login-walled calendar; getting through it forces the session, proxy and anti-detection layers to be real. Everything after inherits them and gets cheaper.

Phase 1 · now Italy Schengen via VFS GlobalHardest first. Exit criteria: a real Mumbai slot appears, the operator's phone buzzes in under 60 seconds. 5 days
Phase 2 The other 22 VFS Schengen countriesGermany, Netherlands, Austria, Greece, Portugal, Switzerland, Poland and the rest. UK visas come free — same provider. config rows
Phase 3 TLScontact and BLSFrance, and Spain where the jurisdiction routes to BLS. At this point every Schengen country an Indian applicant can file for is covered. ~1 day each
Phase 4 USA — AIS / CGI FederalTechnically the easiest checker: clean JSON, light anti-bot. A different product though — reschedule-to-earlier, not find-a-slot, and reschedules are capped per application. ~2 days
Phase 5 Anything released in batchesCanada and Australia visas, passport renewal and reissue appointments, biometrics, document legalisation. The engine does not care what it is watching. plug-in shape
Never Auto-bookingNot a phase. Changing it is a business decision with legal and client-liability weight, and it would have to be made deliberately and in writing. by design
The honest generalisation

This is a slot-scarcity engine. Visa appointments are just the first scarce-slot market.

Strip the domain away and what is left is a machine that watches a source which releases inventory in unannounced batches, detects the change in seconds, and puts it in front of the one human who can act on it — with the context of who is waiting already attached. Visa slots are a good first market because the scarcity is severe, the stakes per slot are high, and the incumbent method is a person refreshing a browser. They are not the only market shaped that way.

The moat is not the scraper. Scrapers get rewritten. The moat is that this is the version an agency can actually put its name on: it never touches a client account, never stores a credential, and never puts a customer's ₹16,000 at risk to save the operator thirty seconds.