Configuring authentication and headers

In this step, you must define the authentication and configure one or more headers if required.

The following options are available for authentication:

  • None/User-defined

  • Basic Authentication

  • API key

  • Bearer Token

You can add any entries (key/value pairs) in the header. Detailed information on this can be found in section Add header.

Type

Select the type of authentication here.

Dynamic dialogs Please note that different input and selection fields are displayed depending on the authentication selected, which are required for the respective authentication.

Below you will find a description of the individual authentication options.

None/User-defined

Use the "None/User-defined" type if no authentication is required or if authentication takes place via other means, such as by setting your own header with credentials.

Reuse client for session-based requests

If you select the type "None/User-defined", the option "Reuse client for session-based interaction" is available.

Activating this option is particularly useful in connection with logging in to an API and if the API assigns session cookies. The REST-API client can store these and reuse them in subsequent REST call actions within the same process.

Background Intrexx uses the "Apache HTTP Client 5" as a REST API client. This is generated with every REST call action and deleted after it has been executed. You can prevent the REST API client from being deleted with the "Reuse client for session-based requests" option. In this case, the client is stored in an Intrexx-internal registry. For further REST call actions within the same process, Intrexx searches the registry to see if a suitably configured client already exists. If this is the case, Intrexx will automatically use this client.

As the client stores and delivers session cookies, a login remains valid until the end of the respective process.

If a client is reused, this is indicated in the log file with "Getting retained Client ...".

Basic Authentication

Use the "Basic Authentication" type if the API expects basic authentication.

Username

You can enter the user name freely or obtain it from the resource mapping or combine both.

Password

You can enter the password freely, obtain it from the logon information store(logon information store) or via resource mapping.

API key

Use the "API key" type if the API expects an API key and the associated information.

Token

The token or API key can be entered freely, obtained from the resource mapping or a combination of both.

Authorization Header

Here you can select which header is to be used for the API key. The following options are available:

  • Authorization: Apikey

  • X-API-Key

    For the options "Authorization: Apikey" and "X-API-Key", the selected option is displayed in the table in the "Header" area and the token is inserted automatically. The created entry cannot be deleted manually from the table in the Header area. The corresponding header is generated when the REST call is sent.

  • Custom

    If you select the "Custom" option, you must create the header yourself.

Bearer Token

Use the "Bearer Token" type if the REST call requires authentication with a bearer token.

Token

The token can be entered freely, obtained from the resource mapping or a combination of both.

With this option, an entry with the key BEARER_TOKEN is always entered in the header table. This entry cannot be deleted manually from the header table. When sending the call, the REST-API client uses the Authorization: Bearer header.

Add header entry

The headers for the request are entered in the header table. In default mode, the headers are generated automatically by the Apache client, so that in most cases no custom headers need to be written. If headers are still required (e.g. for a self-created authentication), you must enter the header entries as key/value pairs. If headers are set in the dialog, they overwrite default headers with the same key. Resource mapping is applied to both the keys and the values of the headers, so dynamic headers are possible. A typical use case would be to place a dynamically generated token in a header (if this is not already covered by the API Key or Bearer Token options).

Step-by-step guide

To add a header entry, proceed as follows:

  1. Open the REST call action.

  2. Switch to the "Authentication and header" tab.

  3. Click on the icon.

    The "Add header entry" dialog box is displayed.

  4. Enter a key and a value. You can enter the value manually or obtain it from the resource mapping or use a combination of both.

  5. Click on "OK".

    The added header entry is displayed.

Your next step

Configure request