API Management at PZU: a shared gateway to its systems and a plan for AI agents

API Management was meant to help PZU leave its SOA platform

Azure API Management was one element of the strategy PZU developed at the turn of 2021 and 2022 to transform its integration area. PZU did not adopt it with AI agents in mind. Before it, PZU built an internal hybrid iPaaS-type platform and deployed a new business process engine. One component was missing: a facade that gives access to these tools. At PZU it is called a “lightweight proxy.” The strategy was meant to allow a smooth exit from the SOA platform, and the combined requirements added up to a recipe for API Management.

Today API Management sits at the entry point, and the integration platform runs between it and the backends. The SOA platform, from the era of products like BizTalk, used to be the main integration architecture. Its potential is slowly running out, though.

Krzysztof Radzimowski, Product Delivery for the integration area at PZU: “We need something much more flexible. Something that lets us adapt ourselves to the business, not the other way around.” (translated) 04:46

Another important goal was to attract the APIs that bypassed the integration platform at the time. Some of them still bypass it today. PZU wanted to bring these APIs and their development teams onto the platform to gain economies of scale and build a very attractive API portfolio. That was the main motivation, and it is still what matters most to PZU: the portfolio is meant to feed new solutions, automation and AI agents. Intelligent API orchestration needs as many interesting and useful APIs as possible.

The self-hosted gateway kept the data flow on PZU’s side

PZU operates in a regulated industry, and API Management is a cloud service. Under earlier regulatory requirements for the cloud, PZU had a number of doubts and concerns. The answer was the self-hosted gateway, a hybrid architecture: it is a cloud service, but the data flow stays on-premises, on PZU’s side. This made the platform rollout easier. PZU deployed API Management together with Protopia.

Today PZU is a little less afraid of the cloud. In the meantime it did a great deal of work to adapt to new regulatory requirements. API Management is no longer its only cloud solution, because PZU has moved into the cloud very boldly. With other solutions it has already met the regulatory recommendations, and the integration team can build on that. That is why PZU is preparing, with more peace of mind, to launch the cloud gateway, which it has not used so far.

Business units and partners treat APIs as the natural way to integrate

The integration team’s main customer is the business side, which represents the external customer: claims handling, policy sales and also the back office. The back office handles customer requests and has to reach data outside the company. The business has largely learned to use APIs and treats them as the natural way to communicate. For PZU’s partners and for startups that offer PZU their solutions, the API is also the entry point.

PZU tends not to expose APIs that anyone can use. The B2B model prevails: an external company agrees on what information it will receive. An internal business partner comes with a need to work with some organization and contacts the integration team. The team makes that cooperation easier, and sometimes makes it possible in the first place.

Traffic goes both ways. PZU exposes functions of its sales, policy or claims system to an external organization. It can also bring in external services, which often improve claims handling, for example, and use them in internal processes.

An insurance comparison site gets quotes through API Management

One of the popular insurance comparison sites sends policy parameters through an API, receives a quote and compares it with other offers. PZU built this integration with the external customer in mind. In this channel it exposes the policy system’s API, and the whole process runs through API Management. The integration team is responsible for securing this API.

The gateway also allows comparison tests: some requests can go to the API and some to another system, to compare how they behave. Rules in API Management can redirect a customer to the call center if the system does not respond fast enough, though not necessarily on the comparison site.

Gateway policies provide accountability for government registries

The second example is data from government registries that PZU retrieves from outside. Accountability is the ability to document, at the request of the institution that provides the data, who asked for it and when, and what data they received. The business that uses the registries has to ensure it. API Management has this data anyway, so it stores it in separate databases from which it can be retrieved later. The business does not have to collect it on its own.

PZU still uses this pattern on the SOA platform today and carried it over to API Management. The response from a registry system that requires accountability can be stored selectively for chosen operations and, if needed, even for individual calls. This logic lives in the policies and in the API itself. Accountability is one of the regulator’s requirements that the integration area has dealt with for more than ten years.

The API client does not always have to worry about this, because the shared platform does it. If callers integrated with an API directly, every calling application or every API would need its own logic to store the data.

Developers get security and observability out of the box

PZU expects a calling system to have a very simple way to authorize access and identify itself to the platform. Backends can have their own methods, such as a key or a certificate, depending on whether internal developers, external developers or a vendor designed them. API Management authenticates to each system in the right way. Callers connect to the gateway in one standardized way.

The security and accountability layer is not enough to attract the developers of domain systems. So PZU also gives them observability built on the platform, out of the box. The developer only publishes an API or connects to one. The integration team takes care of the rest, including security in the built-in policies.

Developers publish APIs themselves, and the integration team runs the platform

At PZU, developers have access to the environment and configure their own APIs. The integration team has two roles. It is a Center of Excellence that provides know-how and a governance model. It is also the platform owner: it runs the platform, is responsible for its stability, and introduces the necessary level of standardization and permissions.

A high degree of self-service was a goal of the rollout, and today it works. A developer who wants to publish an API defines it in the development environment and can set it up by clicking through the interface. Soon they will do it more simply, directly from their own code. Developers should work with API Management as if it were a module of their own application, without getting into the details. Helpers built on the Management API for API Management serve this purpose and are meant to let developers handle things on their own.

A number of development teams already expose APIs and use the integration team’s code repository with growing confidence. Before anyone gets more permissions on the platform, they have to learn how to work with it and show that they share responsibility for it. Estimates put the number of APIs in the non-production environments at more than 50 today, probably closer to 100.

The integration team enforces one hidden standard and organizes APIs in API Center

Probably the only standard in place that a developer may not know about is the set of policies that feed observability tools with the data needed for diagnostics. Developers are sometimes not used to following someone else’s guidelines, so the integration team enforces this standard. The standard is well documented, and developers know what to expect in API Management. PZU does not do classic hardening today, such as removing headers, unless someone asks for it. The APIs are used mainly internally.

In parallel, the team is doing a lot of work on standards that are meant to catch departures from agreed good practices as early as the development stage. As a result, an API that reaches the non-production environments, and later production, should be much more mature. The drivers are automation, AI agents and AI in general.

Krzysztof Radzimowski: “We need standards that make it possible to understand what an API does directly, without any extra tools, for example for AI mechanisms.” (translated) 19:48

PZU is adopting Azure API Center slowly for now. The service works practically out of the box, but many of its features are still only on the roadmap. It automatically reads the data that is already in API Management and lets the team organize APIs that are not in API Management yet. It is a front door to what PZU already has in the API area. PZU sees how much Microsoft is changing API Management and API Center, and it is optimistic that API Center will mature fairly quickly.

Without a cloud gateway, PZU will find it hard to serve AI agents

PZU is investing heavily in the use of AI agent models and is adopting AI tools more and more boldly, just as it is doing with the cloud. The integration team wants to take part in projects that use AI components. Here API Management offers AI Gateway and support for the Model Context Protocol (MCP). Without them, agents, especially external ones, find it hard to communicate with PZU’s APIs.

AI Gateway is the use of API Management in front of AI models, roughly speaking in front of ChatGPT or OpenAI. It shows who is calling, how, how many times and how many tokens they use. All requests and responses can go to internal logs. Another feature is semantic caching.

At the time of recording, AI Gateway had probably been available for more than a year, but only in the cloud gateway, and PZU was not using it yet. That is why, at the time, PZU needed to move to the cloud gateway sooner. PZU expects that if it cannot offer a cloud gateway, it will find it very hard to give anything attractive to internal AI projects and to external agents that want to use its APIs.

API exposure, accountability and access security, for example how many tokens a given process may use, were the topic of workshops planned for September. PZU also hoped to run an internal hackathon later that same year to connect API Management with AI models. It was meant to help people get familiar with what is available in the cloud.

For PZU, showing the technologies is easy. The harder part is to describe a business need ambitious and broad enough to deliver with these tools. The needs the team runs into can often be met much more simply, without such sophisticated technology. PZU hopes that showing the possibilities will encourage the business to go a step further, and that a project using AI Gateway and Azure Logic Apps will come up in the near term. PZU uses Logic Apps as an orchestrator, and various conversations suggest that Logic Apps are also widely used to build AI-based agents and pipelines.

PZU has built a portfolio of integration technologies

As recently as about five years ago, PZU had two large bus-type integration platforms. To a large extent they forced architects to use them and to fit the business need to the platform. Today PZU has a portfolio of integration technologies that let it fit the integration area to the real needs of the business without excessive compromises. The integration team built this portfolio over several years and is looking for more components for it. In the team’s view, the work paid off.

The portfolio includes a file import mechanism that PZU built together with Protopia. It is a dual-use technology: it handles file transfer and event processing, but it can also carry independent application logic, such as notifications that a file was uploaded.