The CallRESTEndpoint is a function that allows for calling REST web services. Use this function simply dragging it into a Function in the Linx Application Designer and configuring the properties required by the service to be called.

Listed below are all configuration options for the CallRESTEndpoint function.



The authentication properties are needed when authentication is required by the web service being called. This does not apply to custom authentication implementations where the username and password are commonly passed as parameters to the web service. For Windows authentication, this requires a Windows user and security for the site defined in Internet Information Server (IIS).


The type of authentication configured on the server for the web service being called. Most common is Basic.

Use default credentials

Available when the selected Type is "Windows".

When this field is checked, the credentials of the currently logged in Windows user will be used.

When this field is not checked, the Domain, Username and Password properties will display to specify custom Windows credentials.


The domain to authenticate the user against.


The username to authenticate against.


The password to authenticate against.



Most web services are configured to accept messages using GET or POST. Some may also use HEAD, PUT or DELETE.


The base URL to use for the service request. This excludes any parameter-specific information that are send with the request. A valid example for this field could look like this:

Query string

A list of parameters to use in order to build up the query string. A query string with a format similar to the following will be generated (note that parameters have not been URL encoded to improve readability):


Arguments and data are commonly transferred using the headers of a call. You can add data to the headers if the web service requires this.

Body format

The Body of a request needs to be in the format that the web service understands. If you are not sure which value to use, the standard and most likely value is 'Text'. The developers of the service you are trying to call should be able to assist in identifying the correct value.


The payload of your web service call in the format specified by the Body format property. If you pass data in the body, you cannot use the GET method, but need to use POST instead.

Request Signing (Certificate)

Sign with certificate

Specifies whether the client should expose a certificate with which to sign requests.

Certificate path

The certificate to use to sign requests.

Request signing (OAuth)

Sign request

Specifies whether the request should be signed using the OAuth authentication standard.

Encryption key

The key used to encrypt the request when signing.


This section allows to configure the structure of the data that is being returned from the web service.

The supported return formats are JSON, XML, or a plain string.

Output type

The value type to use when interpreting the response. The List option indicates whether the response should be interpreted as a list of values. The List option requires you to use JSON or XML for the Body format.

If you create a Type and you have formatted your response accordingly, you can point the Output type field at your user defined type. After the service has executed, Linx will map the return result to the specified structure. Any field that is specified in the return structure that is not present in the response will be ignored.

List content type

Indicates the value type for the items in the list. This option is only visible if the Output type is set to List.

Web proxy

These settings are applicable only if you or the server you're contacting are using a proxy server.

Proxy name

The IP address or URL of your proxy server.


The web service call is commonly performed over port 80, but you can change that if you have configured the service or proxy to use a different port.

Bypass on local

While you are developing the function you may have a different setup from the live environment. When this property is checked, the proxy setup is ignored for your local machine.


Handle all status codes

Check this property to handle success and error responses.

When checked, it will display 2 execution paths – “Success” and “Error”. Successful requests (response status code 200-299) will go into the “Success” execution path, while all other responses will go into the “Error” execution path. Do note that invalid requests, e.g. trying to connect to an invalid address will still throw an exception (and not go into the “Error” execution path). The “Error” execution path is only there to handle invalid responses.

Allow untrusted certificates

Select 'True' to allow connections to sites that make use of untrusted (e.g. self-signed) certificates.


The timeout value for the web service call.

Max response content size

The maximum amount of bytes response content can contain.