aktivvo-cli 0.1.0

CLI client for the Aktivvo / Padam booking API

Aktivvo CLI

Kleines Python-CLI, das die Aktivvo-Website nicht per Browser steuert, sondern dieselben Padam-API-Calls wie das Frontend verwendet.

Wichtige Grenze

Die POST-Endpoints sind auf start.aktivvo.padam.io durch CrowdSec / reCAPTCHA geschützt. Das Tool umgeht diese Hürde nicht.

Praktisch heißt das:

1. Im Browser die Aktivvo-Seite öffnen.
2. Falls das CrowdSec / reCAPTCHA erscheint, dort freischalten.
3. Falls Buchungen gemacht werden sollen, normal im Browser einloggen.
4. Entweder aus den Browser-Devtools den vollständigen Cookie-Header für https://start.aktivvo.padam.io kopieren oder login-browser / import-cookies nutzen.
5. Diesen Cookie-Header dem CLI übergeben.

Wenn der Cookie-Header authz_pdm=... enthält, zieht das CLI den Token automatisch daraus und setzt Authorization: Token .... Bei OpenID-Sessions nutzt es Bearer.

Stand 16. März 2026 ist für diese Deployment-URL kein belastbarer reiner CLI-Username/Password-Login nachweisbar: POST /api/v1.7/signin liefert auch mit mobilen Padam-Headern nur 500, und OpenID ist in der Web-Konfiguration leer. Der praktikable Login für die CLI ist daher ein browsergestützter Session-Import.

Installation

python3 -m venv .venv
source .venv/bin/activate
pip install -e .

Basisnutzung

Cookie einmal in eine Umgebungsvariable legen:

export AKTIVVO_COOKIE_HEADER='crowdsec=...; authz_pdm=...'

Oder direkt aus Chrome importieren:

eval "$(aktivvo import-cookies --browser chrome --format env)"

Oder den Login direkt aus der CLI anstoßen, Browser öffnen lassen und auf die Session warten:

eval "$(aktivvo login-browser --browser chrome --format env)"

Falls schon eine gültige Session im gewählten Browser-Profil liegt, gibt login-browser sie sofort zurück. Für einen echten Neu-Login:

eval "$(aktivvo login-browser --browser chrome --wait-for-new-token --format env)"

Falls macOS den Keychain-Zugriff blockiert oder hängen bleibt, kann das Safe-Storage-Passwort auch explizit gesetzt werden:

AKTIVVO_SAFE_STORAGE_PASSWORD='...' aktivvo import-cookies --browser chrome --format env

Nodes für ein Gebiet anzeigen:

aktivvo search-nodes --territory holzwinkel --limit 20

Aktuellen Benutzer prüfen:

aktivvo current-customer

Suche auf Basis zweier Node-IDs:

aktivvo search \
  --territory holzwinkel \
  --from-id 1055 \
  --to-id 1056 \
  --datetime '2026-03-17T10:00:00+01:00'

Search-Response analysieren:

aktivvo inspect-search search-response.json

Direkt aus einer gespeicherten Search-Response buchen:

aktivvo book-from-search-response \
  search-response.json \
  --territory holzwinkel \
  --payment-method onboard \
  --customer-id 111 \
  --indications 'Bitte an der Bushaltestelle warten'

Buchung finalisieren:

aktivvo book \
  --territory holzwinkel \
  --reservation-history-id 12345 \
  --customer-proposition-id 67890 \
  --payment-method onboard \
  --customer-id 111 \
  --indications 'Bitte an der Bushaltestelle warten'

Reverse-Engineerte Payloads

Die wichtigsten Payloads sind direkt aus dem Frontend-Bundle abgeleitet:

• Suche: POST /api/v1.7/get-rides-multinode
• Finale Buchung: POST /api/v1.7/validate-booking
• Proposition-Validierung: POST /api/searchrequests/{searchRequestId}/propositions/{propositionId}/validate/
• Aktueller Nutzer: GET /api/customers/current/ mit Accept: application/json; version=2.0
• Cookie-Import: lokales Chromium-Cookie-DB-Parsing auf macOS mit Keychain-Entschlüsselung

Die CLI ist absichtlich roh gehalten und gibt JSON aus, damit man Responses zuerst inspizieren und danach gezielt weitere Calls bauen kann.