Integration Strategy — xtoura-app × Busflow Coexistence
Core question: Instead of sunsetting xtoura-app, can we keep it alive (for all operators, including non-Busflow customers) while selectively surfacing Busflow capabilities to Busflow-powered operators through the xtoura-app?
The Hybrid Model
The idea splits the app's feature set into three tiers:
┌─────────────────────────────────────────────────────┐
│ Tier 1: xtoura-only features (all operators) │
│ Interactive Catalog, Checklist, Office Finder, │
│ Surveys, Newsletter │
├─────────────────────────────────────────────────────┤
│ Tier 2: Busflow-enhanced features (Busflow ops) │
│ Booking via Busflow widget (replaces redirect), │
│ Real-time trip data from Busflow API, │
│ Wallet pass deep-links │
├─────────────────────────────────────────────────────┤
│ Tier 3: Busflow-exclusive features (Busflow only) │
│ Live ETA, driver GPS tracking, self-service │
│ rebooking — these stay in Busflow Passenger Portal│
└─────────────────────────────────────────────────────┘How It Works
- xtoura-app stays alive as a standalone product for operators still using it.
- For Busflow operators: The xtoura-app detects (via tenant config) that the operator runs on Busflow and activates Tier 2 integrations — replacing the legacy booking redirect with Busflow's widget URL, pulling trip data from Busflow's API, and linking to Busflow wallet passes.
- The deep operational features (Live ETA, driver tracking, automated rebooking) stay exclusively in Busflow's own Passenger Portal. These require tight integration with Busflow's real-time backend and cannot be surfaced through a loosely-coupled API integration.
Integration Touchpoints (Tier 2)
These are the concrete integration points between xtoura-app and Busflow, ordered by effort:
1. Booking Widget URL Swap (Effort: ~1 day)
Current state: xtoura's BookingBlock.vue opens an external booking_url in an in-app browser. The URL is configurable per operator via the admin configurator.
Integration: For Busflow operators, set the booking_url to the Busflow booking widget URL. No code change required — just a configuration change in the admin interface.
Impact: Passengers browse trips in xtoura → tap "Zur Buchung" → land in Busflow's checkout flow → Busflow handles payment, confirmation, and ticketing.
2. Interactive Catalog → Busflow Trip Links (Effort: ~2 days)
Current state: The interactive catalog has hotspots with tripId and tripDateId fields that link to xtoura's internal trip detail pages. There is also an external field for arbitrary URLs.
Integration: For Busflow operators, set hotspot external URLs to Busflow booking widget URLs (e.g., https://operator.busflow.app/book/trip-123). This lets passengers tap on catalog pages and land directly in Busflow's booking flow.
Impact: The partner's physical catalog becomes a direct acquisition funnel for Busflow bookings.
3. My Trip Data from Busflow API (Effort: ~2–4 weeks)
Current state: The "My Trips" feature pulls booking data from Kuschick/Turista ERPs via dedicated backend modules. This is the most complex integration.
Integration: Add a new NestJS backend module (busflow) alongside the existing kuschick and turista modules. This module calls Busflow's API to fetch booking data, documents, and trip details for passengers whose operator runs on Busflow.
Prerequisite: Busflow must expose a passenger-facing read API (GraphQL or REST) that xtoura's backend can call with a passenger token. This aligns with Busflow's API-first architecture — the API already exists for the Busflow Passenger Portal; xtoura reuses the same endpoints.
Impact: Busflow operators' passengers see real-time booking data in xtoura, replacing the stale Kuschick/Turista data pull.
4. Wallet Pass Deep Links (Effort: ~1 day)
Current state: xtoura offers PDF downloads for booking confirmations and vouchers.
Integration: For Busflow operators, replace the "Vorgangsdruck herunterladen" and "Voucherdruck herunterladen" buttons with "Zum Apple Wallet hinzufügen" and "Zum Google Wallet hinzufügen" deep links pointing to Busflow's pass generation endpoint.
Impact: A taste of Busflow's superior passenger experience — inside the xtoura-app.
Why This Works Strategically
For the Partner (Short-Term Good Faith)
- Their app investment survives. We enhance it rather than ask them to abandon it.
- The app improves for free. Busflow-powered operators get a better experience inside the xtoura-app without the partner writing any new code (Tier 2 integrations require minimal xtoura changes).
- Non-Busflow operators keep working. Operators on other systems continue using xtoura as before. No disruption.
- The partner controls the narrative. They tell operators: "Our app now works with Busflow too — you get the best of both worlds."
For Busflow (Long-Term Natural Selection)
- Low effort, high signal. The integrations above cost 1–4 weeks total. This is negligible compared to the relationship value.
- Busflow becomes visible inside the partner's ecosystem. Every Busflow-enhanced feature in the xtoura-app is a silent demo of Busflow's capabilities.
- The sunset happens naturally. Once operators experience Busflow's Passenger Portal directly (Live ETA, wallet passes, self-service rebooking), they will ask: "Why do I need two apps?" The partner does not need to be told to sunset — the operators will pull.
- The app becomes a legacy wrapper. Over 12–24 months, the xtoura-app's value proposition narrows to the unique features (Interactive Catalog, Office Finder, Surveys). These are niche — the ex-employee can maintain them profitably without competing with Busflow.
The Natural Evolution Timeline
Phase 1 (Now → +3 months): Configuration-Only Integration
├─ Swap booking_url to Busflow widget for Busflow operators
├─ Update interactive catalog hotspots to Busflow booking URLs
└─ Effort: ~3 days, zero xtoura code changes
Phase 2 (+3 → +9 months): API Integration
├─ Add Busflow backend module to xtoura-backend-nest
├─ Replace legacy ERP data with Busflow API data for Busflow ops
├─ Replace PDF downloads with Wallet Pass deep links
├─ Dependency: requires xtoura developer (ex-employee) cooperation
└─ Effort: ~2–4 weeks xtoura development
Phase 3 (+9 → +18 months): Natural Sunset
├─ Busflow Passenger Portal ships (Live ETA, self-service, etc.)
├─ Operators compare: xtoura shows booking data; Busflow shows live GPS
├─ Partner organically deprioritizes xtoura-app investment
└─ xtoura-app handed to ex-employee for niche maintenanceWhat Busflow Must Build (Our Side)
For this hybrid model to work, Busflow needs:
| Requirement | Status | Notes |
|---|---|---|
| Public booking widget URL (per operator, per trip) | Planned (H1) | Already in the Commerce pillar roadmap |
| Passenger-facing read API (booking data, trip details) | Planned (API-first) | The Passenger Portal will consume this same API |
| Wallet Pass generation endpoint (public URL) | Planned (H1) | Part of the Digital Wallet Passes feature |
None of these require building anything for xtoura. They are all features Busflow builds for itself. xtoura simply consumes the public surface.
Risk Assessment
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| Partner interprets Tier 2 as "Busflow taking over our app" | Low | Medium | Frame as enhancement, not takeover. Partner controls which operators activate Busflow integration. |
| xtoura-app development slows to zero before Busflow Portal ships | Medium | Low | Phase 1 requires zero xtoura code changes. Phase 2 can wait until Busflow API is ready. |
| Operators prefer xtoura's familiar UI over Busflow's new portal | Low | Low | Natural user migration takes time, which is acceptable. Both apps serve the same data. |
| Ex-employee refuses or fails to maintain xtoura | Medium | Medium | Offer 6-month maintenance SLA. Document everything during Phase 2. |
| Partner demands Busflow features only surface through xtoura (no standalone portal) | Low | High | Non-negotiable: Busflow's Passenger Portal ships independently. xtoura gets the API, not exclusivity. |
Partner-Facing Arguments
See Partner Pitch for the full set of six USPs and pitch lines for the partner conversation.