How to Publish a REST API to X-Road?
These instructions guide Security Server administrators through the process of adding and registering a new subsystem in X-Road and configuring a REST API service for it. They cover both cases where the subsystem already exists and where it needs to be created, including approval steps and expected status changes. The guide also explains how to publish a REST service with an OpenAPI 3 service description, enable it, configure its access rights, and manage TLS certificate verification. The goal is to complete the basic setup required to make the service available to other X-Road members.
- 1.1 1. Add a New Subsystem
- 1.2 2. Subsystem Status and Naming Behavior
- 1.3 3. Configure the Service
- 1.4 4. Enable and Verify the Service
- 1.5 5. Review and Edit the Service URL
- 1.6 6. TLS Certificate Handling
- 1.7 7. Configure Access Rights
- 1.8 8. Upload TLS Certificate (If Needed)
- 1.9 9. Testing the Service (Optional)
- 1.10 10. How to construct the service URL on the client Security Server (Example)?
- 2 Related articles
1. Add a New Subsystem
In the Clients view, locate the Member who is publishing the service.
Click the Add subsystem button in that Member’s row.
In the Add subsystem view:
If the subsystem already exists in the global configuration:
Click Select Subsystem and choose it from the list.
If the subsystem does not exist:
Enter the Subsystem Code and Subsystem Name.
In both cases, leave the Register subsystem checkbox selected.
Click the Add subsystem button.
Confirm the registration by clicking Yes in the confirmation dialog.
2. Subsystem Status and Naming Behavior
You will be redirected back to the Clients view, and a notification “Subsystem added” will appear at the bottom of the page.
The newly added subsystem appears in the Clients list with the status “Registration in progress.”
If the subsystem was newly created, its name appears as “Undefined.” This is expected and will be updated once registration is complete.
If the subsystem already existed, the correct name will be displayed immediately.
The registration request must be approved on the Central Server:
This may be done automatically or manually, depending on the Central Server’s configuration.
If automatic, the status typically updates to “Registered” within a few minutes. Reload the Clients view to refresh the status.
3. Configure the Service
Click the subsystem name to open its details.
Go to the Services tab.
You may configure the service even if the subsystem registration is not yet complete.
However, other X-Road members cannot invoke the service until both registration and service configuration are finalized.
Click Add REST.
In the Add REST service view:
Select OpenAPI3 Description as the URL type.
Enter the OpenAPI3 specification URL in the URL field (e.g.,
https://d14r9k0rinox9f.cloudfront.net/yaml/x-road-stats.yaml).Enter the Service Code (e.g.,
TestAPI).
Click Add.
4. Enable and Verify the Service
The Security Server fetches and parses the OpenAPI description.
The service is added to the Services list but is disabled by default.
Enable it by toggling the switch on the right side of the service row.
A notification “Service description enabled” will appear.
Click the “>” symbol on the left to expand service details.
Click the Service Code to open the full details.
5. Review and Edit the Service URL
The Service URL is extracted from the OpenAPI
servers.urlfield.This URL is where the Security Server forwards incoming requests.
If the parsed value is incorrect, it can be manually edited.
6. TLS Certificate Handling
More information about the different TLS certificate verification configuration options is available in the Security Server User Guide.
By default, Verify TLS certificate is enabled.
This means the Security Server verifies the API’s TLS certificate.
To enable verification, upload the API's certificate in the Internal servers → Information System TLS certificate section.
If you prefer not to verify the TLS certificate:
Uncheck Verify TLS certificate.
In this case, no certificate upload is needed.
Click Save to apply the configuration.
7. Configure Access Rights
More information about defining access rights is available in the Security Server User Guide.
In the Access Rights section, click Add subjects.
Click Search without entering any criteria to list all registered subsystems.
Select the desired client subsystem(s) and click Add selected.
The selected subsystems now appear under Access Rights. It has access to all the endpoints that belong to the REST API.
Alternatively, instead of giving access to all the API endpoints, it’s possible to define access rights on an endpoint level. Open the Endpoints tab to view the list of endpoints parsed from the OpenAPI description and define access to them separately.
Click Close to return to the Services view.
8. Upload TLS Certificate (If Needed)
If TLS verification is enabled, go to the Internal servers tab.
In the Information System TLS certificate section, click Add to upload the API’s TLS certificate.
9. Testing the Service (Optional)
Go to the Security Server where the client subsystem is registered.
Go to the Internal Servers tab of the client subsystem.
Change the Connection type to HTTP (by default, the connection type is HTTPS).
The connection type HTTP is insecure and therefore, it should be used for testing purposes only. Instead, the connection type HTTPS should always be used in production.
When the connection type is HTTPS, the TLS client certificate of the consumer information system must be uploaded to the consumer Security Server. The certificate is uploaded under the client subsystem, in the Internal Servers tab, within the Information System TLS Certificate section.
More information about the different connection types is available in the Security Server User Guide.
Send a test request to the client Security Server. For example:
curl -X GET \
-H 'X-Road-Client: TEST/GOV/1234/TestClient' \
'http://<CLIENT_SECURITY_SERVER_HOST>:8080/r1/TEST/GOV/1234/TestService/TestAPI/instances'Note: You have to use the same client and service identifiers that you used when configuring the client and service.
10. How to construct the service URL on the client Security Server (Example)?
For example, the base path of the REST API is
https://api.stats.x-road.global/v1, and the API exposes an endpoint at/instances. When invoking the endpoint directly, the full request URL is:
https://api.stats.x-road.global/v1/instancesHowever, when invoking the same endpoint over X-Road, you must replace the REST API's base path with the client Security Server's REST interface URL and append the X-Road service identifier as path parameters, following this format:
http://<CLIENT_SECURITY_SERVER_HOST>:8080/r1/<INSTANCE_IDENTIFIER>/<MEMBER_CLASS>/<MEMBER_CODE>/<SUBSYSTEM_CODE>/<SERVICE_CODE>/<REST_API_ENDPOINT>For example, the direct API endpoint:
https://api.stats.x-road.global/v1/instancesBecomes the following URL when invoked over X-Road when the service identifier is
TEST/GOV/1234/TestService/TestAPI:
http://<CLIENT_SECURITY_SERVER_HOST>:8080/r1/TEST/GOV/1234/TestService/TestAPI/instances