On 7 May 2026, the Interoperable Europe Portal held the peer learning session titled “API gateway enablers”. The event included keynote presentations by Joe Dowling from the Irish Information Mediator team, and Eelco Hotting together with Lonneke Dikmans, from the Dutch Federated Service Connectivity team. The session delivered a comprehensive overview of each solution, examined their operational mechanisms, discussed the requirements that prompted their development, and presented real-world examples provided by implementers. The discussion emphasised key benefits, challenges, lessons learned and offered recommendations.
Below are the highlights per solution.
Information Mediator
The initial segment of the session addressed the Information Mediator, a reusable component developed in Ireland to support secure digital document and data exchange. This solution serves as an integral part of national infrastructure, functioning as a central nervous system by enabling secure interoperability and connectivity among various departments. Leveraging the Apache Camel interoperability engine and the DOMIBUS gateway, the Information Mediator offers out-of-the-box capabilities that allow systems to be integrated seamlessly without the need for developing solutions from the ground up.
The presentation outlined several key insights such as:
- Purpose and applications: the solution addresses the increasing demand for secure digital communication across various sectors and enables rapid integration of new services, while safeguarding internal systems against unexpected data spikes or external disruptions.
- Benefits for citizens: individuals experience improved efficiency in public expenditure and comprehensive compliance integrated into all mediated interactions.
- Technical capabilities: the system supports both synchronous and asynchronous processing pipelines, enabling efficient management of diverse task workloads. Utilising a schema-agnostic framework, it addresses platform variability and ensures consistent compatibility across different environments.
- Active use cases: current implementations encompass a digital wallet for secure document retrieval, and the Once Only Technical System Single Digital Gateway which facilitates cross-border evidence exchange. These initiatives are engaged by key Irish departments such as the Road Safety Authority, the General Register Office, and the Department of Social Protection.
- Future development: upcoming enhancements will feature an operational shock absorber designed to manage significant data spikes, an integration simulator to facilitate seamless connectivity, and adapters aimed at improving compatibility with emerging technologies. Additionally, the adoption of Cloud storage will support long-term sustainability.
- Hackathon 2026: the team has announced a Hackathon for 2026 designed to demonstrate the capabilities of the solution. Participants will have access to the Developer Portal and Software Development Kit, enabling them to explore a range of operational scenarios.
Information Mediator: Feedback session
The presentation was followed by an interactive session where participants and the Portal team raised several technical and operational questions:
Portal team Q&A
Part of it was already supported. Our strategy is really to make the Information Mediator’s source code available, so make it open source and involve it into a fully-fledged application and platform. So, reusability would be high because of that. We are following established patterns to ensure consistency in the source code. In order to address this particular requirement, we rely more on configuration than on refactoring newly written code. For use cases that require specific customisations, we are using open-source solutions. One of those is Apache Camel and so our platform is designed to be future proof, and we will employ adapters and connectors to be able to address those use cases. So, this makes the assessment for interoperability straightforward for public authorities.
The primary lesson was that software engineering is actually about people, not code. So, processes and conscious approaches, really have to do a lot about what to adopt as a technology, managing organisational change, fortuning and innovation mindset. Dynamics like those are challenges everyone is passing through. Technically, the most significant hurdles were establishing connectivity in between disparate systems. So, this often involves restrictions, security protocols, and all sort of diverse configurations. Sometimes we deal with systems that are not actually available through regular channels, internet or public APIs, so we need to implement it from the ground up. In this case, we have to walk through not just the technical implementation, but every requirement gathered and find solutions to the problems that would occur. So yes, we are learning and decreasing the time that we take to actually put those integrations in place. We are faster in every iteration cycle and we will be more than happy to share these with anyone.
Participants Q&A
We have not given thought on the process that we would need to have in place for citizens to identify bugs. We do have processes in place when we are working with different government departments for them, to open tickets and give feedback, but for citizens we do not yet have a process for bug identification. The Information Mediator is a piece of middleware. Therefore, the citizen does not see the Information Mediator, instead they see it as an application or a portal that is connected to it. So, if they are going to be raising a bug, they will raise a bug on the website or portal that they are using to access the service. Then it is the application maintenance team's responsibility to investigate it. If the problem is related to the Information Mediator, they would feed it through the internal channels to the support we have. We certainly need to establish a process to ensure that all tickets or feedback created for client-facing applications targeting the source system are effectively managed.
It is a system that has been built to solve both of those problems. So, within the national level in Ireland there is something called life events, which is, citizens doing a journey through government services. The Information Mediator has been used in the national context to interconnect many different government departments. At the same time, it has been used for the single digital gateway and the Once Only Technical System. So, it has been built to serve both those (the DOMIBUS is a SOAP based system), because they are quite similar. So, there is a conversion that needs to happen between the SOAP messaging and the rest of the interfaces that the Irish government departments are using, so that's part of what it does, but ultimately it does solve both of those needs.
Moreover, it does do back-office connectivity. Some of those building blocks were shown at the start of this presentation, such as the messaging payments and the digital wallet. There is back-end connectivity between all of those systems and between other government departments. It is not only just feeding user interfaces or client-facing systems. Actually, most of the communication is backend because those solutions have a frontend, but the backend is part of the building block, the target system, the source system, and we are in the middle, so the most common use case is actually a backend connecting to us. Then we process that information and send it towards another backend system and handle all the complexities of those transactions, that do not normally follow the same pattern or standard.
Obviously, other countries are having similar solutions because this is coming from GoldStack and we are reusing the patterns that are there. So, connecting or helping the interconnection with other European countries, that's where the Information Mediator sits – in the middle. We manage all the communications through DOMIBUS, and then it is transformed into our queue and that queue talks to our Information Mediator and then we send those messages around to the different evidence requester and all that. So, it is definitely in the middle of everything, and it is a back-office exchange information tool. It is not facing customers.
So connected to that, our strategy is to make the Information Mediator’s source code available as open source. We are currently midway through that journey, but it is involving being a fully flat platform. We are trying to build it in a way that can be reused. If other countries are interested in using it or collaborating with us to evolve it, that would be amazing because then solutions built by different countries, could work towards one united solution for everybody.
Federated Service Connectivity
The second part of the session addressed the Federated Service Connectivity, presented by representatives from the Dutch Ministry of the Interior and Kingdom Relations and Stichting RINIS. This solution is characterised as a standardised framework that facilitates peer-to-peer data exchange in a consistent, secure, and automated fashion.
The presenters noted that the project was launched in 2018 in response to a marked increase in API adoption. Previously, each inter-organisational communications initiative required the development of a bespoke connection, as there was no shared integration layer. Navigating diverse infrastructure components posed unique challenges for each connection and often resulted in completion timelines extending over several weeks or months.
To address operational bottlenecks encountered with a central gateway solution, capable of processing fifteen thousand transactions per second, the team implemented a peer-to-peer federated architecture. This strategic decision to avoid a central processor ensures that citizen data remains distributed and under the control of its respective government entity, supporting privacy requirements. The peer-to-peer federated model also allows organisations to scale their infrastructure horizontally during peak demand, thereby removing centralised limitations.
The presentation emphasised several important insights regarding the Federated Service Connectivity, which are outlined below.
- Methodology and implementation: the framework utilises a rigorous methodology to standardise operations across custom implementations and recognised gateways, with substantial support provided by Open Federated Service Connectivity, which serves as an open-source reference implementation grounded in international standards.
- Technical architecture and capabilities: the system is designed to facilitate machine-to-machine data exchanges between outgoing gateways and incoming gateways, intentionally bypassing direct user interfaces or native frontends.
- High performance and automation: programmatic contract negotiation is managed by designated personnel and is particularly suited to automation through scripts and APIs, enabling new connections to be established in seconds rather than months.
- Security, identity and contracts: cryptographic trust and bilateral authentication are achieved through mutual Transport Layer Security using certificates issued by the Dutch government’s Public Key Infrastructure. Automated contracts strictly define peer access during specified validity periods, with immediate termination of data flow upon contract invalidation.
- Service discovery and delegation: consistent service discovery enables endpoints to be published to a central, shared directory for seamless access. Endpoints are also accessible through an API or frontend registry. The delegation feature secures Software-as-a-Service interactions by designating municipal identities without exposing sensitive government credentials and maintains the ability for immediate revocation as needed.
- Open source and mandatory standards: all developments are available as fully open source under the European Union Public Licence in public repositories. The formalised standard is required for government acquisitions exceeding fifty thousand euros, unless a formal justification is provided.
Federated Service Connectivity: Feedback session
The presentation was followed by an interactive session where participants and the Portal team raised several technical and operational questions:
Portal team Q&A
Although obtaining the Interoperable Europe solution label was not our original objective, its alignment with the broader ecosystem in the Netherlands is now evident. We have implemented standards for General Data Protection Regulation-compliant logging and API design, which facilitate the standardisation of API functionality, as the Federated Service Connectivity specifically serves as the connection layer. This enables seamless Hypertext Transfer Protocol traffic and expedites the establishment of new connections between organisations that previously did not exchange data. The standardisation process is well developed in production environments. We employ the Management and Development Model for Opens Standards, which effectively addresses the requirements of a country or a large consortium of organisations. While it may be less cost-effective for only two organisations to establish a connection, this framework is highly recommended for larger collectives or national initiatives.
One of the primary challenges relates to determining which party initiates the action. Central registries typically do not encounter significant difficulties, as they mandate that any entity connecting to them must comply with their established protocols. As a result, every organisation utilising central registry data is required to adopt these specific procedures for connection and auditing. In contrast, municipalities face considerable obstacles, as they are required to interface with more than sixteen, and in some cases up to thirty two, distinct systems. If each system operates differently, it becomes extremely challenging for municipalities to effectively manage and maintain their infrastructure. Accordingly, it is imperative to encourage central registries to provide their services in a standardised format, especially since the initial investment or cost often falls to organisations that may not be the direct beneficiaries.
Currently, we are engaged in initiatives involving the Once Only Technical System and an identity wallet project to assess whether a government agency can provide a unified API capable of interacting with various European standards. As previously noted, the Federated Service Connectivity standard was developed as an internationally applicable framework, not limited to Dutch requirements, and can readily be adapted for use in other countries by specifying local or European identification numbers relevant to the national context. Accordingly, within the scope of digital wallets and the Once Only Technical System, it would be advantageous to utilise this standard alongside eDelivery or potentially implement both frameworks in tandem. We see significant potential for future advancements through close collaboration with other member states.
In addition, from a data spaces standpoint, the data spaces protocol incorporates contractual agreements. While these protocols place greater emphasis on the messaging layer, leveraging Federated Service Connectivity as an underlying framework for the data spaces layer presents a notable opportunity. With regard to eDelivery, we are actively investigating the requirements necessary to formally integrate APIs into eDelivery mechanisms. Although previous efforts in this area did not achieve substantial progress, we would be highly interested in collaborating with other countries that share this objective.
This framework is designed to meet the requirements of a country or a substantial consortium of organisations. Its implementation may not be cost-effective for just two entities seeking connectivity. Conversely, large groups of organisations or nations should evaluate its potential benefits as part of their strategic considerations.
The standard is not specifically tailored for the Dutch context. Instead, it is designed as an international framework that can be adopted by any country. It may be adapted to local requirements, allowing for the definition of national identification numbers or European numbers that are standardised within the respective jurisdiction. Accordingly, within the broader scope of digital identity wallets and the Once Only Technical System, the standard can be effectively employed in conjunction with eDelivery, or through an integrated approach using both frameworks, to support secure cross-border exchanges.
The initial step involves recognising that the standard is fully open source and accessible on Git servers under the European Union Public Licence. Effective adoption requires providing open-source software components that are production-ready, security-assessed, and performance-evaluated, along with centralised technical support. This approach ensures that both user organisations and external commercial software vendors can confidently implement this new standard.
Participants Q&A
We conducted multiple visits to Estonia to engage directly with the local development team due to the high quality of the concepts they were implementing. Nonetheless, it became apparent that the platform's performance did not meet our specific transaction requirements. In 2018, for example, we were unable to achieve more than ninety requests per second on a reference server equipped with two cores and eighty gigabytes of memory, while our operational objective was approximately twenty thousand requests per second.
Additionally, there is a significant disparity in transaction scale between our countries, as Estonia has a smaller population and a more limited digital service landscape. Moreover, X-Road utilises centralised components, which we have deliberately chosen to avoid due to our guiding principles; our architecture is intentionally designed to function without a central processor or intermediary. Finally, our decentralised approach enables organisations to seamlessly integrate our standard with their existing corporate API gateways, while a centralised infrastructure would have required them to completely restructure their local systems.
A comprehensive ecosystem has been established under the oversight of governing bodies comprised of senior officials at the municipal, provincial, and national levels. These bodies are responsible for setting high-level strategic direction, with all public authorities contributing to a central fund valued at approximately four hundred million euros per year. As initiatives are financed through this collective fund, agencies that choose to pursue independent alternatives are required to finance such projects themselves.
As a result, senior officials direct their internal teams to adhere to the prescribed standard procedures. Although there are no statutory penalties or explicit sanctions for non-compliance, an established review process is in place. Periodic public reports are issued that clearly outline which standards are being implemented by funded organisations. Given the complete transparency and accessibility of this information, failure to comply with the mandated standards presents considerable reputational risk, thereby providing further motivation for adherence.
Most data exchange is conducted over the public internet. In addition, a separate government network infrastructure is employed, connecting multiple public organisations through fibre optic cables. This dedicated and isolated network operates as an independent initiative, supported by its own distinct funding arrangements.
Organisations connected to the fibre network may choose to implement the Federated Service Connectivity on top of it to establish their connections; however, there is no obligation to maintain a separate physical network for this solution. Rather, the network layer is logically defined by group identifiers, enabling all peers within a designated group to efficiently identify and communicate with each other solely through parameters set in their automated contracts, employing standard, widely adopted protocols.
During our preliminary analysis in 2018, we identified a limited number of advanced solutions purpose-built for modern APIs. Our evaluation included eDelivery, which utilises SOAP XML messaging standards. Due to its stateful architecture, eDelivery presents significant challenges in achieving horizontal scalability and leveraging cloud-native capabilities within contemporary API environments. At present, eDelivery follows a four-corner model that permits API usage between corners one and two, as well as between corners four and three, but notably restricts API interactions between corners two and three.
Although eDelivery remains an effective solution for certain European contexts in the Netherlands, it is not ideally suited for scenarios where the primary objective is to implement fully automated, scalable APIs. While specific examples of restricted use cases are not presently available, automating, configuring, and achieving horizontal scalability across cloud-native environments presents significant challenges when using traditional messaging networks. In our system architecture, functionality such as reliable messaging is addressed at the business layer rather than the data layer. As a result, if a service becomes unavailable, buffering and store-and-forward processes are managed above the connection level.
Closing remarks
For further details, you can visit the dedicated pages of the Information Mediator and Federated Service Connectivity.
The session concluded with a presentation of future events. Do not miss the Portal’s User Group Meeting on 4 June 2026. Also, do not forget to register to the Interoperable Europe Academy Seasonal School taking place on 9 and 10 June 2026.
If you were unable to attend this peer learning session – or would like to revisit the key insights and content shared, you can check out the presentation slides attached below as well as the session’s recording.
Do not forget to also complete the Portal’s short Feedback Survey. It helps us align future offerings and improve the Portal experience for all users.