Importing Services

In situations, where your source system in which you store service data isn't supported out of the box or you do not want a pull connector to access your systems (due to security reasons) you can push service data via this REST API into VSM.

Besides general metadata around the service, you can also provide key-value pairs of service-specific data.

Step 1: Calling the VSM API


Getting a Bearer Token

To authorize your API call you need to get a bearer token. See the docs on how to do so.


Getting the <BASE URL> to construct endpoint URL

To call the endpoint you need to know the BASE URL of your workspace. The BASE URL is displayed in integrations page (Top right use profile icon -> Settings -> Integrations).

Please note that access to the Integrations page is exclusive to administrators.


curl --request POST \
     --url \
     --header 'accept: */*' \
     --header 'authorization: Bearer '' \
     --header 'content-type: multipart/form-data' \
     --form id=svc1234dasd \
     --form sourceType=cicd \
     --form sourceInstance=prod \
     --form name=ai-engine \
     --form 'description=A crazy AI engine' \
     --form 'data={"number_of_incidents":"2","monitoring_dashboard":""}'

πŸ” API attributes in more detail:

  • sourceType describes the system you are fetching the data from e.g. CI/CD. This will help later to understand the different systems a given service is connected to.
  • sourceInstanceis the entity from within the source system you're connecting to. Think of this as a staging environment (prod,test...) or an grouping entity (company A, company B), in cases where the source systems contains multiple org units. This will help later on to understand from which different instances from within a source system information came from
  • id is the external id your service carries in the source system. Not to be confused with VSM's internal ids

For more details on the API, please refer to the API documentation:

GitHub Action to import services

If you use GitHub actions you may want to use our GitHub Action to import your services automatically from your CI/CD pipeline.

Step 2: Mapping your service

After the API call has fired, go to the mapping inbox and map the discovered service a) to an existing service or b) create a new service from it. Once, mapped any subsequent API call will update the source data in that service.

Step 3: Build your service catalog

After you've mapped your service via the mapping inbox, you will see a new tab, which represents the source system from which this service came (note: the name of the tab is identical to thesourceType parameter you passed in the curl).
From here we show the key-value pairs you passed via the data attribute in the curl. This helps you to store simple metadata about the service on this page (more improvements to come πŸš€ ).