---
title: "VIA Rail and JonView supplier integrations | Manas Nikam"
canonical: https://manasnikam.dev/case-studies/via-rail-jonview-supplier-integration/
updated: 2026-09-23
---


# Integrating VIA Rail and JonView into a tour operator's booking system

By Manas Nikam, May 2023 to present (ongoing). Client work.

For Fresh Tracks Canada I integrated the JonView supplier API into the itinerary system and later built the VIA Rail integration end to end; per-product booking time went from about 10 minutes to about 30 seconds, and I am the dominant author of the supplier module with 124 of 330 commits.

## Context

Fresh Tracks Canada sells Canadian rail vacations from Vancouver. Its booking management system is about 20 repositories: Django and FastAPI services, a Next.js front end, PostgreSQL, Elasticsearch, Redis, on AWS, with a two-way Salesforce sync. I have been its systems architect on contract since May 2023, working Pacific-time overlap from Mumbai and aligning technology work with the Director.

Constraint: the itinerary system stayed live throughout; every supplier had its own timeouts, outages and product quirks, and none of that could reach the sales team's screen.

> Scoping artifact. The VIA Rail integration, my third supplier, was built as a dated sequence: scaffold (13 July 2026), API client, per-user objects, business class, graceful failure handling (3 September 2026). The sequence is the scope; each step shipped on its own.

## Problem

Sales staff needed to search and book supplier products from inside the itinerary system; booking a single product by hand took about 10 minutes, and quotes went cold while they waited.

## What I built

I integrated the JonView supplier API into the itinerary management system so staff search and book products in place, with supplier timeouts, downtime and itinerary-to-supplier state sync handled explicitly. Later I added dynamic hotel availability, product linking, synced cancellations and value-adds, and a rule that skips products with malformed supplier responses.

I then built the VIA Rail integration end to end and a Rocky Mountaineer scraper, and fixed the Redis cache timeouts and batch-job database connections that surfaced as the supplier module grew. I am the dominant author of the supplier module (124 of 330 commits).

## Architecture

Django and DRF service (`bms-service-supplier-connect`) with a per-supplier client, a circuit breaker for JonView (`jonview/circuit_breaker.py`), a websocket router and consumers for live updates, Redis caching, batch jobs for availability, PostgreSQL, and GitHub Actions per-environment deploys.

1. Sales staff in the itinerary system (Next.js)
2. Supplier-connect service (Django, DRF)
3. Per-supplier client with circuit breaker and timeouts
4. JonView, VIA Rail, Rocky Mountaineer APIs
5. State sync back to the itinerary and websocket updates to the screen

Request path: the itinerary front end calls the supplier-connect service; each supplier has its own client behind a circuit breaker; results and cancellations sync back to the itinerary and push to the screen over websockets.

### Rails to Django migration, the groundwork

Before the supplier work I led the migration of a Ruby on Rails application to Django and React. I redesigned the process logic with the Product Owner first, then migrated the app. API response times got 80 to 95% faster by minimizing SQL calls and caching static data in a NoSQL store (client report; self-reported percentage).

Stack: Python, Django, Django REST Framework, PostgreSQL, Redis, WebSockets, AWS ECS, GitHub Actions, Salesforce, SonarQube.

## Results

Per-product booking time went from about 10 minutes to about 30 seconds, and quote conversion improved (the client’s figure; I do not publish a percentage I cannot source). Three supplier integrations are live.

Alongside this I designed, built and documented alone a PostgreSQL fleet monitor (11 metrics, alert thresholds, add a server by editing one secret, no deploy) whose spec was approved before a line of code, on 23 July 2026; it has [its own case study](/case-studies/postgres-fleet-monitoring/). I also designed and prototyped CrewAI agents for the 20 to 50 daily supplier emails the operations team handles, with human approval through Teams Adaptive Cards; whether that prototype went live is not something I will claim here.

Supplier integration outcomes at Fresh Tracks Canada

| Measure | Before | After | Source |
| --- | --- | --- | --- |
| Booking time per product | about 10 minutes | about 30 seconds | client measurement |
| Supplier integrations built by me |  | 3 (JonView, VIA Rail, Rocky Mountaineer) | git history |
| My share of supplier-connect commits |  | 124 of 330 | git author count |
| VIA Rail build, scaffold to graceful failure | 13 July 2026 | 3 September 2026 | git history |

## What I'd do differently

On VIA Rail, graceful failure handling was the last step in the sequence. Next time I would pull the failure-mode list (timeouts, supplier downtime, malformed product responses, state drift between our system and theirs) to the front and build the circuit-breaker path in the first week, because those four classes are what every supplier integration on this project eventually needed.

## Links

- [bms.freshtracks.com](https://bms.freshtracks.com): customer-internal system, login required; no public demo
- [freshtrackscanada.com](https://www.freshtrackscanada.com): the client