Contact person: Business Client

Phone:Show

Email:Show

Location: Seville, Spain

Budget: Recommended by industry experts

Time to start: As soon as possible

Project description:
"ChatGPT Plus
Project title

TLScontact Accounts Monitoring System (multi-account, multi-city) — Python / Playwright

Short summary

I need a monitoring application that logs into many TLScontact accounts (up to ~50), grouped by city, checks each account every ~2 hours for a change of status (especially: an appointment assigned / moved to payment stage), and immediately notifies me when that happens. The system must also detect account errors (locked/expired), handle CAPTCHA by requesting manual intervention, keep session state to avoid repeated logins, and keep an event log/db. The solution must be production-ready and easy to run on a VPS.

Important: please do not use the word "bot" in your proposal. Describe technical approach and deliverables.

Full specification / requirements
Core features

Multi-account login

Accept an input file (CSV) with columns: id, name, email, password, city, (optional) interval_seconds.

Log into each account using provided credentials.

Per-account scheduling

Default check interval: ~7200 seconds (2 hours). Per-account override allowed.

Introduce small random jitter so not all accounts run at the same time.

Status detection

For each account, detect whether the account progressed to the next stage (appointment assigned / payment step).

Detect "no appointment" state.

Detect account errors: locked, expired session, authentication failed, blocked, etc.

Detect presence of CAPTCHA / anti-bot challenge and flag it for manual action.

Notifications

Immediate notification on important events (appointment assigned, account error, CAPTCHA).

Notification channels required: Telegram (using Telegram API token and chat id) and email (SMTP config optional).

For CAPTCHA events include a screenshot saved on disk and reference in the notification.

Session persistence

Save session state (cookies/storage_state) per account to avoid re-login every run.

Auto-refresh session state after successful login/check.

Concurrency & rate-limiting

Support parallel checks (configurable max concurrency), but protect against spikes.

Reasonable defaults: MAX_CONCURRENT = 4–8.

Respect site usage: exponential backoff on repeated failures.

Robust logging & DB

Record events to SQLite (or other lightweight DB): account_id, timestamp, event_type, details.

Keep historical logs for audits.

Error handling & manual remediation

If account shows an error or CAPTCHA, mark it and send notification so an operator can intervene manually.

Provide instructions/command for operator to re-run login for a specific account.

Config & secrets

Use .env or config file for secrets (Telegram token, SMTP, headless flag).

No secrets hard-coded.

Deployment

Provide instructions to run locally and as a service (systemd or Docker).

Optionally provide a Dockerfile.

Optional (nice-to-have)

Small web dashboard (Flask / FastAPI) to view account status and logs.

Sound alert or push notification integration.

Proxy support (per-city or per-account) for rotation if recommended.

Technology preferences

Preferred stack: Python 3.10+ + Playwright (headless/headful depending on CAPTCHA handling). Async approach preferred.

DB: SQLite (simple), optionally support export to CSV.

Notifications: Telegram API (token + chat id) and SMTP for email.

Packaging: clear README, [login to view URL], and optionally Dockerfile.

Deliverables

Source code repository (Git) with:

Main monitoring program.

Config templates: .env.example.

[login to view URL] example.

requirements.txt.

README with setup and run instructions.

SQLite database schema + sample entries (or empty DB created on first run).

Clear instructions for:

Creating Telegram token & chat id (how to get them).

Running Playwright and installing browsers: playwright install.

Running headful mode for manual CAPTCHA solving.

Systemd service file OR Dockerfile and run instructions (choose one; Docker preferred).

Short demo: screenshots or short screencast (screen recording) showing:

A test account flow where an “appointment found” is detected and notified.

Example of CAPTCHA detection and screenshot saved.

Minimal test harness or instructions for local testing (how to simulate appointment state if possible).

30 days basic support for bugs discovered after delivery (specify).

Acceptance criteria

The program can read [login to view URL] and run checks for all accounts concurrently with configurable concurrency.

When a test HTML (or real account) contains appointment information, the system triggers a Telegram (and optional email) notification with account id and details.

When CAPTCHA is encountered, a notification is sent and a screenshot file is saved.

Sessions are persisted between runs (storage_state or cookie files).

Logs are written into SQLite and can be queried.

Documentation is clear enough for me to deploy on a Linux VPS and keep running as a service.

Security & compliance

Do not commit secrets to the repo.

All credentials remain local in .env or in the [login to view URL] file provided by me.

The solution must avoid aggressive scraping that could cause IP bans; include sensible timeouts and retries.

Developer must mention how they will respect TLScontact terms of service and suggest best practices (rate limits, proxies only if necessary).

Proposal questions (what I expect bidders to answer)

Approach — Short description of how you will implement login/session persistence and how you will detect appointment state (DOM selectors approach).

CAPTCHA handling — How will you detect CAPTCHA? How will you surface it for manual resolution? (No automated CAPTCHA bypassing.)

Selectors & maintenance — How will you make selectors maintainable if TLScontact changes markup? (e.g., config file, admin UI, or easy-to-edit constants)

Concurrency & scaling — How many concurrent sessions do you recommend for 50 accounts? How will you avoid site blocking?

Deployment — Will you provide Dockerfile or systemd file? Which OS did you test on?

Deliverables & timeline — Estimated time to finish and final price. (Target timeline: 7–14 days)

Examples — Links to previous similar projects or GitHub repos.

Support — Do you provide post-delivery support for bug fixes? For how long, and at what rate?

Suggested milestone & budget (you can propose alternatives)

Milestone 1 (spec + skeleton, 2–3 days): basic project skeleton, CSV parsing, scheduler, sample login flow — 20% payment.

Milestone 2 (core features, 4–6 days): Playwright login, session persistence, detection heuristics, SQLite logging, Telegram/email notifications — 50%.

Milestone 3 (hardening, docs, Docker, demo, tests): screenshots/screencast, README, Dockerfile/systemd, optional small dashboard — 30%.

Budget suggestion: $250–$450 USD depending on developer experience and final scope (dashboard, Docker, proxies). You may accept lower/higher bids." (client-provided description)