API documentation

    Compound Registration provides a REST interface to interact with the registration system.

    Documentation

    If you have an installed Compound Registration version, you can check the API documentation at:

    https://yourhost.com/RegistryCxn/rest/swagger-ui.html

    In case you don't have a deployed system, you can check the API doc of the latest Compound Registration version on the compreg-demo-swagger-ui. Authentication is needed to use the example REST API, access can be requested here.

    API authentication

    API calls return valid responses, only if the request is authenticated. One way of authentication is Basic Authentication , in this case an "Authorization" header must be added to the HTTP request.

    For example purposes let's consider the case when a client wants to retrieve a compound identified by "CXN132". In this case a GET request must be sent to

    https://yourhost.com/RegistryCxn/rest/structureService/registryStructure?id=CXN132

    To authenticate this request, the proper "Authorization" header must be added, containing the "authorization token". The authorization token is generated from the combination of the base64 encoded username and password pair.

    As an example when the username is "tom" and the password is "password" then the header can be generated

    • on linux with bash
      echo -n "tom:password" | base64
      dG9tOnBhc3N3b3Jk
    • on windows with powershell
      dG9tOnBhc3N3b3Jk
    • or alternatively this web tool could be used

    The full example with "Authorization" in the request header:

    GET https://yourhost.com/RegistryCxn/rest/structureService/registryStructure?id=CXN1 HTTP/1.1
    Authorization: "Basic dG9tOnBhc3N3b3Jk"

    More examples on how to construct an API call can be seen in the payload of developer console in your browser. You can have more info here.

    Forcing compounds to the Staging

    Using the API, compounds can be prevented to be registered and "forced" into the Staging area for further review.

    ID-based fields

    Since version 21.3.0 a new parameter has been added in the settings, bulkloader API: ‘processIdBasedFields’. This configuration option is related to the ID-based dictionaries.

    Example:

    "settings":{
          "type":"MOLECULE",
          "rowDelimiter":null,
          "fieldDelimiter":null,
          "multiValueDelimiter":"",
          "structureField":null,
          "containsHeader":true,
          "processIdBasedFields":true
       },

    -“processIdBasedFields":true: System tries to find the ID of the given Value to save. If it cannot be found, it will try to save the value as is.

    -“processIdBasedFields":false: It tries to save the given value as it is, considering it to be an ID of an entry in the dictionary.

    In both cases additional validation configurations might block these registrations and make them fall to Staging. E.g if the ‘fromList’ validator is added in the field configuration.

    Since version 21.3.0 the registration endpoints also received an additional optional parameter. In case you are using ID-based dictionaries, this way you can provide the IDs of the entry as well. This new option is available inside the Structure’s AdditionalData JSON Array.

    Example:

    "additionalData":[
    {"name":"id_based_field","value":"two","id":"2"},
    {"name":"simple_field","value":"example"}
    ]