back to overview
For agency owners·8 min read

TLScontact appointment booking: how automation works and why it matters for agencies

TLScontact operates Schengen visa centres for France, Germany, Italy, and others across dozens of countries. How TLS appointment booking differs from VFS, what makes it technically harder to automate, and how managed infrastructure handles it at scale.

TLScontact at scale: what agencies need to know

90+
Countries where TLS operates visa centres
Covers Schengen embassies for France, Germany, Italy, Belgium, and others
CF
Cloudflare Managed Challenge on every route
Stricter than VFS — residential IP is required, hosting ASNs blocked at edge
8–14 wks
Typical Schengen appointment wait via TLS
France and Italy corridors from India, Nigeria, Pakistan running longest
3+
Distinct portals depending on issuing country
fr.tlscontact.com, de.tlscontact.com differ in DOM structure and selectors

TLScontact is the second-largest visa outsourcing company in the world. It handles Schengen appointment booking for France, Germany, Italy, Belgium, the Netherlands, and several other member states across most of Africa, Asia, and the Americas. For many applicants chasing a European visa, TLS is the only route.

For visa agencies, TLS presents a different operational challenge than VFS Global. The portals are structured differently per issuing country. The Cloudflare protection is more aggressive. And the appointment dynamics — particularly for French and Italian visas from high-demand corridors — rival or exceed VFS in scarcity. If your agency handles Schengen applications, TLS automation is not optional infrastructure — it is the difference between catching slots and watching them disappear.

How TLScontact differs from VFS Global — technically

1
Per-country portal, not a single global platform
VFS Global runs a single Angular application across corridors. TLScontact operates separate subdomains per issuing country — fr.tlscontact.com, de.tlscontact.com, it.tlscontact.com — each with its own DOM structure, field IDs, and session handling. An automation adapter built for French TLS does not work for German TLS without modification.
2
Cloudflare Managed Challenge, not just Turnstile
VFS uses Cloudflare Turnstile (a passive/interactive widget). TLScontact deploys Cloudflare Managed Challenge on route-level — the challenge fires before the portal renders. This means hosting-ASN IPs are rejected at the CDN edge before any application code is reached. Residential egress is not optional; it is the minimum requirement to receive a page response.
3
Session warmup requirements are stricter
TLS portals apply behavioural fingerprinting that is more aggressive than VFS. Cold browser sessions without prior navigation history trigger challenges more frequently. Effective automation requires session warmup — simulated browsing before reaching the booking flow — and real browser fingerprints, not headless browser defaults.
4
Slot release patterns differ by issuing country
French TLS tends to release capacity in smaller batches at unpredictable intervals. Italian TLS releases larger batches weekly. German TLS is the most predictable — weekly releases on Tuesday mornings CET. Knowing the release cadence for each corridor determines when to run watchers at higher frequency.

What agencies get wrong when trying to automate TLS

Common approach
What actually happens
Reuse the VFS adapter for TLS
Logical — same problem domain
Fails immediately — different DOM, different auth flow, different challenge type
Run from a datacenter IP
Cheaper and easier to manage
CF edge blocks at CDN layer — no response, no session, no portal
Build one adapter for all TLS portals
Seems efficient
Works for one country, breaks for others — each subdomain has its own selector map
Check availability on a fixed schedule
Simpler to implement
Misses slots for France/Belgium which release unpredictably — need adaptive polling
Use managed infrastructure
Delegates the problem
Correct — someone else maintains the selectors, the residential proxy pool, and the logic

Opaige's approach to TLS automation

Why TLS took longer than VFS to productionise
VFS Global's Turnstile was solved by forging a MessageEvent with origin=challenges.cloudflare.com — a technique we developed after months of reverse-engineering the widget handshake. TLS's Managed Challenge fires before the portal renders, which means the entire residential proxy layer has to be in place before any application-level code runs. We reached the TLS dashboard in staging. Production stability at load is the remaining gate — Q3 2026 target.

Opaige maintains separate versioned adapters for each TLS country portal. When the French TLS DOM changes — which happens without notice — the adapter is updated and the change is rolled out to all customers running French Schengen watches. Agencies do not write selectors, manage residential proxy rotation, or monitor for portal breaks. That is infrastructure — and it is ours to maintain.

For agencies handling TLS corridors today: TLScontact is live in production, running behind the same residential proxy layer and per-country adapter matrix we use for every portal. VFS corridors — which cover the majority of high-demand UK and Schengen applications — are live as well.