The challenge
Renotec needed to connect a low-code platform to the Belgian Social Security presence-registration services. The target platform could work with JSON over HTTP, but the external services exposed SOAP operations secured with signed XML, X.509 certificates and SAML assertions. That gap was more than a change of data format: every request had to follow the expected namespaces, security headers, signature references and service-specific message structure.
The integration therefore needed to present a small, predictable JSON API while taking responsibility for the SOAP protocol and its security requirements behind the scenes.
A focused translation API
David built the integration as a .NET 8 isolated Azure Functions application. Each business operation has a dedicated HTTP-triggered function that accepts a typed JSON request. The service translates that model into the corresponding SOAP envelope, calls the Social Security endpoint and converts the XML result into a JSON response the low-code platform can consume directly.
The API supports searching presence registrations, retrieving one registration, registering multiple presences and cancelling registrations. Keeping these operations explicit made the public interface understandable without exposing SOAP concepts to its consumers.
Building and signing SOAP messages
Reusable envelope builders construct the XML document for each operation. A shared base handles namespaces, timestamps, binary security tokens and common message structure, while operation-specific builders create the request body. Unique identifiers connect the body and security elements to their signature references.
The signing component applies exclusive XML canonicalization, SHA-256 digests and an RSA-SHA256 signature using the client certificate. This keeps the protocol-heavy work centralized instead of duplicating security logic across every endpoint.
Token and certificate integration
Before calling a presence-registration operation, the application requests a SAML assertion from the Security Token Service. That assertion is inserted into the signed SOAP security header for the business request. Certificates are loaded locally during development and downloaded through Azure Key Vault in hosted environments, using managed Azure credentials rather than embedding cloud credentials in application code.
Configuration separates test and live service addresses, SOAP actions and operational limits from the implementation.
Translating responses back to JSON
Successful SOAP responses are reduced to the relevant registration payload and deserialized into typed .NET response models. The Azure Function then serializes those models as JSON. This creates a clear boundary: the low-code application works with familiar request and response objects, while namespaces, envelopes and XML signatures remain internal integration concerns.
The search flow also applies a configurable result limit before returning data, allowing the adapter to protect its consumer from unexpectedly large payloads.
Result
Renotec gained a dedicated bridge between a JSON-oriented low-code environment and a security-sensitive SOAP service. Four presence-registration workflows are available through a consistent HTTP interface, while certificate handling, SAML acquisition, message signing and XML conversion remain contained in one deployable integration service. The result lets the business platform use the required government services without taking on SOAP and WS-Security itself.