Engineering Digital
Transformation with
Intelligence
We transform businesses through software innovation and intelligent systems. We enable digital transformation by combining deep engineering capabilities with a strong understanding of business, operational, and industry-specific realities.
INSURANCE/INTEGRATION
The legacy system stays. A modern API layer unlocks everything around it.
SOAP/XML to REST/JSON with FastAPI on AWS Lambda
0
Changes to the legacy system
3
New channels enabled (mobile, partner, self-service)
~$80
Monthly running cost on AWS
At A Glance
Industry
Platform
Legacy
API
AWS
Insurance
Policy distribution, servicing, compliance
SOAP/XML, WS-Security
FastAPI, Pydantic, Zeep
Lambda, API Gateway, Cognito, ElastiCache, CDK
TL;DR
A regional insurer ran its core policy administration on a 15-year-old platform that exposed functionality through SOAP web services only. Three business initiatives (mobile agent quoting, broker platform integration, customer self-service portal) were all blocked by the same constraint. Cogentis built a Python-based API translation layer on AWS: FastAPI with Pydantic models auto-generating the OpenAPI 3.0 specification, deployed on Lambda via Mangum, with Redis caching and a session pool bridging stateless OAuth 2.0 consumers to the stateful SOAP backend. Twelve priority operations were wrapped. The legacy system was unchanged. Three new channels launched. The complete translation layer runs under $80/month.
A regional insurer with approximately 800 employees ran its core operations on a policy administration system built 15 years ago. The platform handled quoting, policy issuance, endorsements, renewals, and claims enquiry for roughly 400,000 active policies across personal and commercial lines. Together, these capabilities supported policy distribution, customer servicing, and regulatory compliance across the insurer’s entire book of business. The system was stable, well understood by the operations team, and deeply embedded in every business process.
The system exposed its functionality through SOAP web service operations, secured with WS-Security tokens and XML message envelopes. A single desktop application used by 120 internal underwriters and claims handlers consumed these services. No external system had ever connected to them. When three business initiatives simultaneously required modern API access to policy data, the SOAP-only interface became the single constraint blocking all three.
The distribution team needed a mobile app for 200+ field agents who were quoting policies on paper forms, then re-keying data at the end of each day. Competitors with mobile quoting were winning business on speed. The partnerships team had signed agreements with two broker aggregator platforms; both required REST API integration with a 90-day deadline. The customer experience team had board approval for a self-service portal. All three were blocked by the same constraint: the legacy system only spoke SOAP.
The Problem
The insurer needed to open three new distribution and service channels without risking the stability of a platform serving 400,000 active policies. Rewriting the policy administration system was a multi-year programme and an existential risk for a regional insurer. The business could not wait two years for the mobile app, the partner integrations, or the customer portal.
The answer was to leave the legacy system exactly as it was and build a translation layer in front of it: a modern REST API that spoke JSON and OAuth 2.0 to the outside world while speaking SOAP and WS-Security to the legacy system behind the scenes.
“The legacy system is not the problem. It is the interface to the legacy system that is the problem. Change the interface, and you unlock the business without touching the risk.”
Why this was hard
The SOAP services had undocumented behaviours. The WSDLs described the happy path but not the 14 distinct error response formats the system returned depending on which validation rule failed, which downstream service timed out, or which session state was inconsistent. Each had to be identified with the help of the client’s senior engineer who had seen them in production, then mapped to structured HTTP error responses with meaningful payloads. This mapping was the single largest manual effort.
The session model was stateful. The legacy system required a session token from a SOAP login operation on every subsequent call. Mobile apps and partner APIs expect stateless authentication. The API layer had to manage a pool of pre-authenticated SOAP sessions in Redis, invisible to consumers. Each request grabs a session, uses it, and returns it. If a session has expired, the layer discards it, authenticates a new one, and retries transparently.
The quoting flow required 4 sequential SOAP operations. Two of the calls were independent and could run in parallel. The API layer parallelised the independent calls, then fed both results into the dependent calls. Four sequential SOAP calls became one REST call, roughly halving the response time.
The solution approach
Cogentis worked alongside a senior engineer from the client’s team who provided the legacy system knowledge that no WSDL can capture: which operations have side effects, which error codes actually occur in production, which test accounts exist in staging, and what session timeout looks like from the caller’s perspective.
The translation layer was built in Python with FastAPI, deployed on AWS Lambda via the Mangum adapter, fronted by API Gateway with Amazon Cognito for OAuth 2.0. FastAPI with Pydantic models was the critical technology choice: the API contract is defined in Python type annotations, and the OpenAPI 3.0 specification is generated automatically. There is no separate spec to write or maintain.
The scope was bounded to 12 priority SOAP operations in three groups: the quoting flow (4 operations aggregated into a single endpoint), policy servicing (policy lookup, coverage summary, document listing and download, endorsement status), and claims (first notice of loss, status lookup, document upload). The error mapping covered all 14 legacy error formats regardless of which operations were wrapped, because any operation can throw any error.
Response caching in Redis handled the read-heavy operations, with polling-based invalidation every 60 seconds. The infrastructure was defined in AWS CDK (Python) and deployed from the CI pipeline.
The client’s team subsequently wrapped the remaining operations using the same FastAPI codebase and the same patterns.
Outcomes Achieved
Three new business channels enabled
- Mobile agent quoting (200+ field agents moved from paper to digital), broker aggregator integration (delivered within the 90-day contractual deadline), and customer self-service portal (policy viewing, document access, claims submission) all connected through a single REST API.
Core operations protected
- Zero changes to the 15-year-old policy administration platform serving 400,000 active policies. Zero risk to underwriting, claims, or renewal workflows.
Agent quoting response time halved
- Four sequential SOAP calls aggregated into one REST call with parallel execution. Cached policy lookups responded in under 100ms, down from 800ms to 1.2 seconds.
Single integration standard established
- Auto-generated OpenAPI 3.0 specification maintained automatically from the code, eliminating separate API documentation. The spec grows as the client’s team adds operations
Viable economics and architectural foundation
- The complete translation layer runs under $80/month on AWS (Lambda, ElastiCache, API Gateway, Cognito). The client’s own team extended it to the remaining operations. The API layer is the architectural boundary for any future backend modernisation: when the legacy system is eventually replaced, every consumer keeps the same REST API.
Frequently Asked Questions
What is the difference between an API gateway and a full application rewrite?
An API gateway builds a modern interface in front of an existing system without changing the system itself. A rewrite replaces the system entirely. The gateway approach delivers new channels (mobile, partner, self-service) in weeks rather than the years a rewrite requires, at a fraction of the cost and risk. The gateway also creates the architectural boundary that makes a future rewrite safer, because every consumer is already on the new API and does not need to change when the backend is eventually replaced.
Why FastAPI on Lambda rather than a traditional application server?
FastAPI auto-generates the OpenAPI 3.0 specification from Python type hints, eliminating separate API documentation. Lambda’s pay-per-request pricing fits the variable traffic pattern of insurance agents and partners (heavy during business hours, minimal at night). The total running cost is under $80/month, which is viable for a regional insurer without enterprise cloud budgets.
How does the session pool solve the stateful SOAP problem?
The legacy system requires a session token from a SOAP login call on every request. Lambda functions are stateless and cannot hold sessions between invocations. The solution is a pre-authenticated session pool stored in Redis: a scheduled process maintains a pool of valid SOAP sessions, each consumer request grabs one, uses it, and returns it. If a session has expired, the Lambda transparently authenticates a new one and retries. The consumer never knows the legacy system is session-based.
At A Glance
Industry
Platform
Legacy
API
AWS
Insurance
Policy distribution, servicing, compliance
SOAP/XML, WS-Security
FastAPI, Pydantic, Zeep
Lambda, API Gateway, Cognito, ElastiCache, CDK