company-info-api
RESTful API managing company information (name, address, contact details) with published client NuGet packages and a Windows sync job that pulls company data from Phenix.
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 |
| Frameworks | ASP.NET Core 10 (minimal APIs), FluentValidation, Scalar OpenAPI |
| Runtimes | .NET 10, .NET Framework 4.6.2 (client packages) |
| Tests / CI | good / CI in place |
| Last commit | 2026-05-19 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Platform services (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | AWS + on-prem Ships artefacts to both AWS and on-prem machines (see evidence below)
|
| Releases | 1 release pipeline(s): \finance\jobs\company-info-sync job |
| Integration | rest, wcf |
| Source | Open in Azure DevOps |
Risk flags
No risk flags recorded.
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loosely attached Bound into the core by 1 mechanism(s).
- Speaks WCF (client)
Detaches 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.
- 27 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
- 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
Replatform company-info-api to modern .NET
Runs on .NET 10, .NET Framework 4.6.2 (client packages), out of mainstream support. No pinning dependency blocks it; sequence by fan-in (providers before consumers).
Impact: Unblocks 27 dependent system(s)
proposedAssessment notes
company-info-api
Purpose
A simple RESTful API to manage company information (name, address, contact details), hosted on AWS but usable on-premise via ConnectionBroker. Publishes NuGet packages (TC.Phenix.CompanyInfo, TC.Phenix.CompanyInfo.Api.Client, TC.ApiClient.Utils) consumed by many estate services (e.g. booking-download, booking-data-exporter). Includes a Windows sync job that copies company data out of Phenix into this API.
Tech stack
- C# on .NET 10 for the API (minimal APIs, source-generated JSON, Scalar/OpenAPI, Phenix JWT bearer auth); client/service packages multi-target
net462;netstandard2.0;net8.0;net10.0for legacy consumers. - MongoDB.Driver with MongoDB.Analyzer; TC.ConnectionBroker (Api/Mongo/Wcf), TC.Cognito.Auth.Client for service auth; central package management and
.slnxsolution. - Sync tool (
tools/TC.CompanyInfo.Sync.*) reads Phenix booking data over WCF (TC.Phenix.Services.Client) and writes via the API client.
Deployment
release_count 1. included.json shows only the sync job pipelines: build company-info-api [sync-job] and release \finance\jobs\company-info-sync job. The repo also carries azure-pipelines.yml (API/package CI) and deploy-mongodb.yml (Mongo script deployment via TC.ScriptRunner.Mongo); the API itself is AWS-deployed outside classic release pipelines.
Dependencies
- Internal: the sync job consumes the legacy Phenix booking WCF service (exact estate repo unconfirmed); many estate services depend on this repo's NuGet packages.
- External: AWS Cognito for client authentication; AWS hosting (AWSSDK.Core).
Data stores
- MongoDB company-info database, with schema/scripts deployed via a dedicated MongoDB pipeline.
Integration points
- REST API with OpenAPI/Scalar; generated HTTP API client package; WCF client (sync job) into Phenix.
Code health
Healthy: six test projects covering API, client, data, common and sync layers; CI plus separate sync-job and Mongo pipelines; active development (last commit 2026-05-19).
Modernisation risks
Low: current .NET 10 API. Residual concerns are the net462 package targets kept for legacy Phenix consumers and the WCF-based sync job, both of which persist a dependency on the legacy Phenix estate.