Configuring authentication and headers

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

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 the section Add header.

Type

Select the type of the authentication here.

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

A description of the individual authentication options is provided below.

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 is 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.

Since 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 as desired or obtain it from the resource mapping or combine both.

Password

You can enter the password as desired, obtain it from the credential store (Credential store) or from the 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 as desired, 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 entry created 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 "User-defined" 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 as desired, 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 the call is sent, the REST-API client uses the Authorization header: Bearer.

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, meaning dynamic headers are possible. A typical use case would be to place a dynamically generated token in a header (if this is not already taken care of by the API key or bearer token options).

Step-by-step guide

Proceed as follows to add a header entry:

  1. Open the REST call action.

  2. Go 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