vibe-api
ASP.NET Core 8 API plus a TypeScript AWS Lambda poller that import corporate bookings from the Vibe.travel online booking tool into TC systems (backoffice invoicing, booking download, VCC payment).
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp, typescript |
| Frameworks | ASP.NET Core 8, MediatR, AWS Lambda |
| Runtimes | .NET 8, nodejs |
| Tests / CI | good / CI in place |
| Last commit | 2026-05-11 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | AI and assistants (system generated; curate in repo-owners.json to override) |
| Product area | TC Co-Pilot |
| Hosted | AWS + on-prem Ships artefacts to both AWS and on-prem machines (see evidence below)
|
| Releases | 2 release pipeline(s): \finance\vibe-api; \finance\vibe-api - Stealth |
| Integration | rest, wcf, redis-streams |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
kernel Bound into the core by 2 mechanism(s).
- Pinning dependency: mailtemplate-service, application-framework
- Speaks WCF (client)
Detaches when its pinning dependencies are cut or multi-targeted (mailtemplate-service, application-framework); and when its WCF surface gains a modern interface or its WCF calls move to one.
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
No excuseNothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Already deploys as a container to AWS, which releases without downtime today. Some artefacts still deploy on-prem; they follow the on-prem path. Separating it from the three-week release is a process decision, not a technical one.
- 2 system(s) depend on this repo; during a rolling deploy they will talk to old and new versions at once, so responses must stay compatible
- Consumes WCF contract packages: never take a breaking client bump mid-feature, and treat obsolete warnings as migration debt
- Serialized state or messages in flight (Redis or queues): new code must deserialize objects written by the previous version
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Route deployments through the Workflow Engine's automated drain, deploy, health-check, return cycle (the path proven by the first automated production run in mid-2026).
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Partially containerisedPart of this repo already builds containers for AWS while other artefacts still deploy to on-prem machines. Finish the job by moving the remaining artefacts (see the hosting evidence on this page) through the same pipeline template.
- Identify the artefacts still deploying through deployment-group release pipelines (listed in the hosting evidence).
- Move each to the shared ci.yml pipeline template with the container parameters, as the already-containerised artefacts in this repo do.
- Disarm the old release pipelines once traffic is confirmed on the new deployment.
Recommended actions
No specific actions for this repo. It either needs only normal maintenance, or its work is covered by an estate-level action. See the full programme.
Assessment notes
vibe-api
Purpose
Everything for the Vibe.travel online booking tool used by corporate customers: a Lambda (vibe-polling) polls the external Vibe backoffice XML service, drops booking files into an S3 bucket and records them in a MongoDB (Atlas) Vibe database; the API then processes those bookings - matching customers/suppliers, raising backoffice sales invoices, feeding the booking-download pipeline and requesting VCCs for payment - and emits booking events onto Redis streams.
Tech stack
C# on .NET 8 (ASP.NET Core Web API, MediatR, FluentValidation, Polly, PhenixAuth, New Relic, Nerdbank.GitVersioning) with per-integration projects (Backoffice, BookingDownload, ContactApi, DestinationApi, DocumentationService, MailTemplate). VibeBackofficeContract parses the vendor's backoffice XML. src/aws-lambdas is a separate TypeScript/webpack/Jest codebase for the polling Lambda.
Deployment
prod_application with 2 releases: build pipeline vibe-api (YAML build.yml; build-node.yml builds the Lambda separately as vibe-poller) feeding release pipelines \finance\vibe-api and - Stealth. The Lambda deploys to AWS; the API to the shared services hosting.
Dependencies
Internal: TC backoffice (sales invoices, customer/supplier lookups, likely via ConnectionBroker WCF), booking-download (TC.BookingDownloadProvider.API.Client), vcc-service (TC.VirtualCreditCard.Api.Client for payment cards), phenix-contact-api (Contact target), phenix-destination-management (DestinationManagement target), backoffice-documentation-booking, mailtemplate-service and backoffice-useraccount-service clients, plus the ConnectionBroker/Exceptions/ApplicationFramework/Diagnostics platform packages. External: the Vibe.travel backoffice service, AWS (Lambda, S3), MongoDB Atlas, New Relic.
Data stores
MongoDB Vibe database (booking records/state, in Atlas, with TC.ScriptRunner.Mongo change scripts), the VibeBookingBucket S3 bucket for downloaded booking XML, and Redis streams for published booking events.
Integration points
Inbound REST; outbound REST to estate APIs, WCF to backoffice, Redis streams for events, SOAP-ish XML polling of the vendor service from the Lambda.
Code health
Good: two xunit test projects (~287 test files) plus Jest tests for the Lambda; excellent docs (docs/Poller.md, SystemDiagram.md, VibeBookingDownload.md with Lucidchart diagrams) and a maintained README with build/release badges. Last commit 2026-05-11.
Modernisation risks
Low priority - modern .NET 8 and TypeScript with good tests, docs and YAML CI. Risks are mostly architectural: a two-runtime repo (Lambda + API) with separate build pipelines, a residual WCF client path to the legacy backoffice, and dependence on the external Vibe.travel vendor XML contract.