Custom NLX/FSC integration development
Appfront builds custom NLX/FSC integrations for secure API traffic within Common Ground. NLX has grown into the FSC standard (Federated Service Connectivity) for federated, logged and authorised API traffic between government organisations. We set up the inway, outway, manager and contracts according to the NL profile, with PKIoverheid certificates, mTLS and transaction logging, so you query data at the source instead of copying it.
What is an NLX/FSC integration?
Within the VNG Common Ground programme, NLX began as an open source component to let API traffic between (government) organisations be federated, logged and authorised. The approach behind NLX has been developed into a formal standard: Federated Service Connectivity (FSC), adopted in December 2024 by the GDI Programming Council. NLX has not disappeared; it lives on as the reference implementation of FSC. In practice, the community speaks of NLX/FSC: NLX as the working software, and FSC as the agreements an implementation must meet.
An FSC/NLX integration lets organisations find, offer and query each other's REST APIs securely without data being copied centrally. Each participant (peer) runs an outway for outgoing traffic, an inway for incoming traffic and a manager that handles contracts and authorisations; a directory registers the connected organisations and their services. Access to a service runs through a contract with a service connection grant, and all traffic is logged per transaction. This way, the integration fits the Common Ground principle: query data at the source.
Appfront builds on the official FSC/NLX documentation and the NL profile for government implementations. Because the standard is still evolving, with extensions for logging, policy and control in progress, we follow the current publications from Logius and VNG and are open about what is settled and what is still being worked out. We align set-up, certificate management and error handling with your existing landscape.
Federated, not centralised
No central data store: each organisation keeps its own data and makes it available through its own inway. Other participants query that service directly at the source, within a shared trust network of peers.
Authorised through contracts
Access to a service only arises after an explicit contract with a service connection grant. Only authorised peers may query a specific API, managed through the manager, with delegation where an intermediary acts on behalf of an organisation.
Logged and traceable
Through the logging extension, every data exchange receives a uniform log record with a unique transaction ID. This makes it traceable per integration who requested what and when, which is mandatory once FSC is used in the Digikoppeling context.
Our development process for NLX/FSC integrations
We work with a proven methodology that removes uncertainty early and delivers a stable integration. From an initial analysis of the APIs to be exposed or queried and the right FSC profile, through to go-live and ongoing management, every step is aimed at an integration your own team can understand and trust.
We map out which APIs you want to offer or query, which peers you will connect with, which FSC profile suits you, and how the integration relates to existing Digikoppeling traffic and your base registries.
We design the set-up of the inway, outway, manager and directory, arrange PKIoverheid certificates and trust anchors for mTLS, and define a logging and error-handling strategy.
Implementation and configuration with contracts and grants, automated tests against the FSC test suite, structured transaction logging and monitoring. You see working integrations along the way.
Controlled go-live with validation of contracts and certificates and a safety net, followed by ongoing management, certificate rotation and further development.
What an NLX/FSC integration concretely delivers
Every FSC/NLX integration is set up specifically for the APIs you offer or query, your base registries and the peers you work with. Below are the features we most often deliver for organisations putting Common Ground into practice.
Inway for your own APIs
We place an inway in front of your existing REST API or source registration, so other authorised organisations can query that service securely. The inway validates, logs and routes incoming traffic without you having to rebuild the underlying application.
Outway for outgoing traffic
An outway lets your applications query other peers' APIs as if they were local endpoints. The outway handles mTLS, selects the right contract and logs every call, so your developers can focus on functionality instead of integration mechanics.
Managing contracts and grants
Through the manager, we set up contracts with service connection grants: who may query which service, and under which conditions. This includes delegation, where an intermediary publishes or consumes an API on behalf of an organisation, so collaborations are properly arranged.
PKIoverheid & mTLS
Setting up mutual TLS between managers, inways and outways using X.509 certificates. In the government context, this is based on PKIoverheid certificates and an agreed set of certificate authorities (trust anchors), including timely rotation so connections remain reliable.
Transaction logging
The logging extension writes a uniform log record with a unique transaction ID for each exchange, so every call is traceable. We configure logging in line with the NL profile and align it with your existing logging facilities for audit and accountability.
Connecting to Digikoppeling
FSC is included in the Digikoppeling REST API interface standard profile. We help you determine how your FSC integration relates to classic Digikoppeling message exchange and, where needed, configure both so they complement each other within your landscape.
Typical use cases in practice
An FSC/NLX integration looks different for every organisation. We regularly see a number of recurring contexts, and for each we have an approach that pays close attention to inway/outway setup, contracts and the requirements around certificates and logging.
Municipalities working with Common Ground
Municipalities putting Common Ground into practice who want to query data at the source rather than copy it. An inway exposes a source register or API; outways let internal applications query other registers securely. A good fit with software for municipalities and a modern municipality website.
Collaborations sharing APIs
Regional collaborations, chain partners and joint arrangements that want to share APIs with each other. FSC governs, per relationship, which organisation may query which service, via contracts with grants, including delegation where an implementing organisation acts on behalf of several parties.
Common Ground component suppliers
Software vendors building Common Ground components or wanting to make existing products FSC-compliant. We handle the inway/outway setup, the connection to the directory and validation against the FSC test suite, so your component demonstrably meets the standard.
Implementing organisations & chain partners
Implementation bodies, water boards and housing associations exchanging data between chain systems with traceable logging. Think of a Haal Centraal integration or a ZGW API integration exposed through federated FSC.
Technology we use
We build FSC/NLX integrations in line with the FSC standard and the NL profile, combined with the backend stack that suits you. The precise setup depends on your source registers, the peers you connect with and your certificate and logging arrangements, so that your own team can manage and further develop the integration.
Why choose Appfront for your NLX/FSC integration?
Appfront has extensive experience building API integrations for a wide range of organisations in the Netherlands. We always start with a thorough analysis of your existing systems and processes. An integration should not only work technically, but also add practical value to the way you work.
For every integration, we write clear documentation and make sure your own team, or any future supplier, can understand and manage it. No black box, just transparent code and clear agreements on monitoring, alerting and maintenance.
You work with a dedicated point of contact who understands both the technical and the functional side. This keeps communication short, prevents misunderstandings and speeds up decisions when choices need to be made during development.
See also our wider services around custom software, housing association software, custom water board software and AI for municipalities and government.
- Familiar with the FSC standard and NLX as the reference implementation
- Experience with inway, outway, manager and directory within Common Ground
- Experienced with contracts, grants and delegation between peers
- Secure by default: mTLS, PKIoverheid certificates and certificate rotation
- Transaction logging in line with the logging extension and the NL profile
- Understanding the relationship between FSC and Digikoppeling
- Clear documentation your team can read and manage
- A fixed point of contact, no account managers passed around
- Ongoing maintenance and proactive further development
- A way of working aligned with your existing government IT landscape
Security and privacy in NLX/FSC integrations
FSC/NLX integrations often expose personal data from source registers, so security and authorisation are central. Traffic between managers, inways and outways runs over mutual TLS (mTLS) with X.509 certificates. In a government context we use PKIoverheid certificates, and the components accept only the agreed certificate authorities (trust anchors), so every party knows exactly which peer it is connecting to. Access is only granted through a contract with a service connection grant.
The logging extension records a uniform log entry with a unique transaction ID for every transaction; within the Digikoppeling context, this logging is mandatory. We build according to data minimisation and least privilege, document the data flows, contracts and authorisations, and align the setup with the NL profile so that your processing register is complete and you demonstrably comply with the GDPR.
Unsure whether FSC, classic Digikoppeling message exchange or a combination is the best fit? Get in touch, we are happy to think it through with you.
- GDPR-compliant data processing and data minimisation
- mTLS with X.509 and PKIoverheid certificates
- Trust anchors and strict peer validation
- Authorisation through contracts and service connection grants
- Transaction logging with a unique transaction ID
- Monitoring and alerting for anomalies
- Certificate management and timely rotation
- Documentation for your record of processing activities
Frequently asked questions about NLX/FSC integrations
Answers to the questions we are asked most often about NLX/FSC implementations.
NLX emerged within the VNG's Common Ground programme as an open source component for federated, logged and authorised API traffic between organisations. The approach behind NLX has grown into a standard: Federated Service Connectivity (FSC). NLX has not disappeared; it lives on as the reference implementation of that FSC standard. In practice, the community therefore usually speaks of NLX/FSC: NLX as working software, FSC as the agreements an implementation must meet. We build integrations that align with that current standard.
NLX as a standalone brand name has largely been absorbed into the FSC standard, which was adopted by the GDI Programming Council in December 2024. NLX itself has not been retired: the codebase is the reference implementation of FSC and is still being developed. For new projects, we therefore always position our work on FSC, with NLX as the implementation. Because the standard is still evolving — extensions for logging, policy and control are under way — we keep to the latest publications from Logius and VNG and phrase our recommendations carefully wherever something is not yet final.
Digikoppeling is the broader family of interface standards for message exchange between government organisations. FSC is the Common Ground API layer that has since been included in the Digikoppeling REST API interface standard profile. Where classic Digikoppeling message traffic is mainly about reliable message transport, FSC/NLX focuses on federated exposure, discovery and authorisation of REST APIs. In an integration project, we help you determine which profile fits and how FSC and Digikoppeling relate in your specific situation. See also our page on Digikoppeling integrations.
An FSC/NLX environment consists of a number of fixed roles: an outway that proxies and logs outgoing API requests, an inway that validates and logs incoming requests and forwards them to the underlying API, a manager that handles contracts and authorisation requests, and a directory in which participating organisations (peers) and their services are registered. Access to a service is arranged through a contract with a service connection grant. We set up these components, connect them to your existing API or source register, and make sure the whole setup remains manageable.
Traffic between managers, inways and outways runs over mutual TLS (mTLS) with X.509 certificates. In the government context, PKIoverheid certificates are used for this, and the components only accept certificates from the agreed certificate authorities (trust anchors). This way, every party knows with certainty which peer it is connecting to. The FSC logging extension writes a uniform log record per transaction with a unique transaction ID; in the Digikoppeling context, this logging is mandatory. We set up certificate management, trust anchors and transaction logging in line with the NL profile.
The cost is determined by the complexity of the data flows, the number of APIs to expose or query, the set-up of the inway, outway, manager and directory, and the requirements around certificates, logging and authorisation. The connection to your existing base registry or Common Ground components and ongoing management also play a part. We always provide a clear quote after a no-obligation analysis of your situation and the desired FSC profile.
Yes, provided it is set up properly. Because FSC/NLX often exposes personal data from source registers, we build to data minimisation and least privilege: only authorised peers gain access to a specific service, via a contract with a grant. mTLS with PKIoverheid certificates secures the transport, and transaction logging makes every data exchange traceable. We document the data flows, contracts and authorisations so that your record of processing activities is complete and you can demonstrably comply with the GDPR.
FSC/NLX suits municipalities and other government organisations that are putting Common Ground into practice and want to query data at the source rather than copy it. Collaborative partnerships that share APIs with one another, and suppliers building or connecting Common Ground components, also benefit from a correct FSC implementation. Not sure whether FSC, classic Digikoppeling message traffic or a combination best fits? We'll look at that with you in a no-obligation conversation.
Ready to build your NLX/FSC integration?
Tell us which APIs you want to offer or query and with which peers you want to connect within Common Ground. We are happy to help you design the set-up of the inway, outway, contracts, certificates and logging in line with the NL profile. A no-obligation first conversation will give you a clear picture of the possibilities and of how it relates to Digikoppeling.