Rest API (Generic)

Nexla's bi-directional connectors can both send data to and receive data from any data system. This means that once a user has created or gained access to a credential for any data system, building any data flow to ingest data from or send data to a location within that data system requires only a few simple steps.

With the REST API connector, Nexla users can connect to almost any REST API-based data system without requiring a system-specific pre-configured connector. The REST API connector supports use cases of any complexity—from fetching a JSON object array from a public URL to incremental loading and calling multiple API endpoints—as well as multi-level and chained API calls.

Nexla also includes templatized REST API-based connectors for many data systems. To view a list of these connectors and specific user guides, see the REST API page.

1. Credentials

This section provides information about and step-by-step instructions for creating a new REST API credential in Nexla.

1.1 Add a New REST API Credential

1. After selecting the data source/destination type, in the screen, click . This will open the Add New Credential window.

     

2. Enter a name for the credential in the Credential Name field.

     

3. Optional: Enter a description for the credential in the Credential Description field.

     

4. Select "Generic REST API" from the API Type pulldown menu.

     

5. Select the API authentication mechanism that will be used with this credential from the Authentication Type pulldown menu, and continue to the steps in the corresponding subsection.

   • API Key (Section 1.2)
   • AWS Signature (Section 1.3)
   • Basic Auth (Section 1.4)
   • Google Service Account (Section 1.5)
   • No Auth Mode (Section 1.6)
   • 2-Legged OAuth 1.0 (Section 1.7)
   • 3-Legged OAuth 1.0 (Section 1.8)
   • 2-Legged OAuth 2.0 (Section 1.9)
   • 3-Legged OAuth 2.0 (Section 1.10)
   • Token (Section 1.11)

     

1.2 Authentication: API Key

Select this mode when the API server requires a key-value API key pair to be sent as a request header or query parameter with every request.

1. Select "API Key" from the Authentication Type pulldown menu.

     

2. Select the location where the API key should be included in each API request from the Where to Add API Key on API Requests pulldown menu.

   • HEADER – When this option is selected, the API key will be included in the request header of each request.
   • URL_PARAMETER – When this option is selected, the API key will be included as a URL parameter within each request.

     

3. Enter the parameter name used for the API key in requests to this API in the API Key Parameter Name field.

   • When HEADER is selected in Step 2: Enter the request header name that should be used for the API key.
   • When URL_PARAMETER is selected in Step 2: Enter the URL query parameter name that should be used to send the API key as a URL parameter.

     

4. Enter the parameter value that should be sent with the API key parameter name in the API Key Parameter Value field.

   • When HEADER is selected in Step 2: Enter the header value that should be sent with the API key parameter name request header.
   • When URL_PARAMETER is selected in Step 2: Enter the URL parameter value that should be sent with the API key parameter name query parameter.

     

5. Continue to Section 1.12.

1.3 Authentication: AWS Signature

Select this mode if the credential will be used with an Amazon Web Services API server. This mode will configure Nexla to use a special type of Hash Message Authentication Code (HMAC) authentication that is designed specifically for use with AWS.

1. Select "AWS Signature" from the Authentication Type pulldown menu.

     

2. Enter the AWS access key that should be included in each request in the AWS Access Key field.

     

3. Enter the AWS secret key that should be included in each request in the AWS Secret Key field.

     

4. Enter the AWS region that will be receiving the API requests sent using this credential in the AWS Region field.

   This field is pre-filled with the nearest AWS region based on the user's location (the location accuracy will vary according to the user's privacy settings). However, it can be easily changed by editing the entry in the field.

     

5. Enter the name of the AWS service that will receive requests sent using this credential in the Service Name field.

     

6. Optional: If the API requires temporary security credentials when receiving requests, enter the session token that should be included with each request in the Session Token field.

   The session token will be added to each request as an x-amz-access-token request header.

     

7. Continue to Section 1.12.

1.4 Authentication: Basic Auth

Select this mode when the API server requires a verified username and password to be sent with each request.

1. Select "Basic Auth" from the Authentication Type pulldown menu.

     

2. Enter the username that should be sent with each request in the Username field.

     

3. Enter the password corresponding to the username in the Password field.

   Nexla will automatically combine the username and password into a Base64-encoded pair to be sent with each request.

     

4. Continue to Section 1.12.

1.5 Authentication: Google Service Account

Select this mode when the credential will be used to access an API server associated with a Google Service Account.

1. Select "Google Service Account" from the Authentication Type pulldown menu.

     

2. Enter the content of the Service Content JSON file generated by Google Cloud AIM for the service that will be accessed using this credential in the Service Account Credentials JSON field.

   The content must be entered as a valid JSON object.

     

3. Enter the OAuth 2.0 scopes for the Google API that should be used with GCP Service Account authentication in the Service Account Scopes field.

   Scopes must be entered as a comma-separated string of one or more scopes.

     

4. Continue to Section 1.12.

1.6 Authentication: No Auth Mode

Select this mode when the API server does not require authentication or when authentication information will be sent as custom request headers or URL query parameters.

1. Select "No Auth Mode" from the Authentication Type pulldown menu.

     

2. Continue to Section 1.12.

1.7 Authentication: OAuth 1.0 (2-Legged)

Select this mode when the API requires 2-legged (server–server) OAuth 1.0-based authentication.

• Nexla supports both 2- and 3-legged OAuth 1.0 authentication methods. To configure this credential for 3-legged OAuth 1.0, see Section 1.8.

• Nexla can also automatically refresh short-lived tokens when this mode is selected.

1. Select "OAuth 1.0" from the Authentication Type pulldown menu.

     

2. Select "2-Legged OAuth1" from the Type of OAuth Exchange pulldown menu.

     

3. Select the method that will be used to sign requests from the Signature Method pulldown menu.

   • For APIs that require requests to be signed using a dynamic signature algorithm, select either HMAC-SHA1 to encrypt the signature with the SHA1 algorithm or HMAC-SHA256 to encrypt the signature with the SHA256 algorithm.

   • If the API does not require requests to be signed with a dynamic signature algorithm, select PLAINTEXT.

     

4. Enter the consumer key used for the OAuth 1.0 client in the Consumer Key field.

     

5. Enter the consumer secret used for the OAuth 1.0 client in the Consumer Secret field.

     

6. Enter the access token used for the OAuth 1.0 client in the Access Token field.

     

7. Enter the access token secret used for the OAuth 1.0 client in the Access Token Secret field.

     

8. Enter any advanced configuration parameters required by the API, such as the realm, version, etc., in the OAuth1 Advanced Configuration (JSON) field.

   Advanced configuration parameters must be entered as a valid JSON object.

     

9. Continue to Section 1.12.

1.8 Authentication: OAuth 1.0 (3-Legged)

Select this mode when the API server requires 3-legged OAuth 1.0-based authentication.

• Nexla supports both 2- and 3-legged OAuth 1.0 authentication methods. To configure this credential for 2-legged OAuth 1.0, see Section 1.7.

• Nexla can also automatically refresh short-lived tokens when this mode is selected.

Important Note: A redirect URL must be configured during three-legged OAuth client setup. Ensure that <your-nexla-ui-url>/oauth1Auth has been set as this redirect URL, replacing <your-nexla-ui-url> with the root URL used to access Nexla.

1. Select "OAuth 1.0" from the Authentication Type pulldown menu.

     

2. Select "3-Legged OAuth1" from the Type of OAuth Exchange pulldown menu.

     

3. Enter the request URL that will be used to fetch the request token in the URL for Request Token field.

     

4. Optional: If additional optional parameters should be attached to the request-token URL, enter these parameters in the Request Token URL Parameters field.

   Request-token URL parameters must be entered in the format key1=value1&key2=value2.

   The oauth\_callback and oauth\_consumer\_key parameters do not need to be included in this field.

     

5. Enter the OAuth 1.0 URL used to initiate user authorization in the Authorization URL field.

     

6. Optional: If any additional optional parameters should be attached to the authorization URL, enter these parameters in the Authorization URL Parameters field.

   Authorization URL parameters must be entered in the format key1=value1&key2=value2.

   Autogenerated properties, properties received from the request URL in the previous step of authorization, and the oauth\_callback and oauth\_consumer\_key parameters do not need to be included in this field.

     

7. Enter the OAuth 1.0 token used to convert the request token into an access token in the Access Token URL field.

     

8. Optional: If any additional optional parameters should be attached to the access-token URL, enter these parameters in the Access Token URL Parameters field.

   Access-token URL parameters must be entered in the format key1=value1&key2=value2.

   Autogenerated properties, properties received from the request URL in the previous steps of authorization, and the oauth\_callback and oauth\_consumer\_key parameters do not need to be included in this field.

     

9. Select the method that will be used to sign requests from the Signature Method pulldown menu.

   • For APIs that require requests to be signed using a dynamic signature algorithm, select either HMAC-SHA1 to encrypt the signature with the SHA1 algorithm or HMAC-SHA256 to encrypt the signature with the SHA256 algorithm.

   • If the API does not require requests to be signed with a dynamic signature algorithm, select PLAINTEXT.

     

10. Enter the consumer key used for the OAuth 1.0 client in the Consumer Key field.

      

11. Enter the consumer secret used for the OAuth 1.0 client in the Consumer Secret field.

      

12. Enter any advanced configuration parameters required by the API, such as the realm, version, etc., in the OAuth1 Advanced Configuration (JSON) field.

    Advanced configuration parameters must be entered as a valid JSON object.

      

13. Click to authorize the OAuth 1.0 client service via the UI.

      

14. Continue to Section 1.12.

1.9 Authentication: OAuth 2.0 (2-Legged)

Select this mode when the API server requires 2-legged OAuth 2.0-based authentication.

• Nexla supports both 2- and 3-legged OAuth 2.0 authentication methods. To configure this credential for 3-legged OAuth 2.0, see Section 1.10.

• Nexla can also automatically refresh short-lived tokens when this mode is selected.

1. Select "OAuth 2.0" from the Authentication Type pulldown menu.

     

2. Select "2-Legged OAuth2" from the Type of OAuth Exchange pulldown menu.

     

3. Enter the client ID used for the OAuth 2.0 client in the Client ID field.

     

4. Enter the client secret used for the OAuth 2.0 client in the Client Secret field.

     

5. Enter the URL used to fetch tokens from the API token server in the Access Token URL field.

     

6. Enter the token type that should be used to attach the OAuth 2.0 token to each request.

   Typically, the token type is set as Bearer, which indicates a bearer token. However, some API vendors use a different name or case.

     

7. Select the type of request method that should be used when sending requests to the OAuth 2.0 token URL from the Access Token URL Method pulldown menu.

   Typically, the access-token request method is set as POST.

     

8. Select the payload mode that should be used to send the OAuth 2.0 client ID and client secret with the token URL from the Authentication Payload Mode pulldown menu.

   • Encoded Header – The OAuth 2.0 client ID and client secret are attached to the authentication header as a Base64-encoded pair.
   • Form Data – The OAuth 2.0 client ID and client secret are attached as form-data payload parameters.
   • Query Parameters – The OAuth 2.0 client ID and client secret are attached to the token query as query parameters.
   • Skip Automatic Inclusion – Nexla will not automatically attach the OAuth 2.0 client ID and client secret. When this mode is selected, the OAuth 2.0 client ID and client secret should be explicitly set in the OAuth2: Token Request Body field in step 9.

     The "Skip Automatic Inclusion" mode is not a commonly used option and should only be used for API vendors that reject the inclusion of client information in any other form.

     

9. Optional: Some OAuth servers require additional payload properties beyond the standard OAuth 2.0 token URL payload properties to be sent with each token URL request. If the OAuth 2.0 server requires additional payload properties, enter these properties in the OAuth2: Token Request Body field.

   Payload properties in this field must be entered in the form of a JSON dictionary.

   Nexla automatically includes standard OAuth 2.0 token URL payload properties such as grant_type, client_id, and client_secret with each token URL request. These standard payload properties do not need to be entered in this field.

     

10. Optional: Some OAuth servers require additional custom headers to be sent with each token URL request. If the OAuth 2.0 server requires additional request headers when obtaining tokens, enter these request headers in the OAuth2: Token Request Headers field.

    Request headers in this field must be entered as comma-separated values—for example, header1:value1,header2:value2.

      

11. Optional: If the OAuth 2.0 server requires additional scopes to be included with each token request, enter these scopes in the API scopes field.

    API scopes must be entered as space-separated values—for example, scope1 scope2 scope3.

    Nexla will automatically attach all entered scopes to each token request as a scope payload property.

      

12. Optional: If the access tokens received from the OAuth 2.0 server are short-lived, check the box next to "Requires Auto Refresh of Token" to configure Nexla to continuously automatically refresh the token to retain a valid access token.

      

    1. Enter the OAuth 2.0 token-refresh URL used to fetch a new access token using the current access and refresh tokens in the Refresh Token URL field.

       Typically, the token-refresh URL is the same as the OAuth 2.0 token URL.

         

13. Continue to Section 1.12.

1.10 Authentication: OAuth 2.0 (3-Legged)

Select this mode when the API server requires 3-legged OAuth 2.0-based authentication.

• Nexla supports both 2- and 3-legged OAuth 2.0 authentication methods. To configure this credential for 2-legged OAuth 2.0, see Section 1.9.

• Nexla can also automatically refresh short-lived tokens when this mode is selected.

1. Select "OAuth 2.0" from the Authentication Type pulldown menu.

     

2. Select "3-Legged OAuth2" from the Type of OAuth Exchange pulldown menu.

     

3. Enter the client ID used for the OAuth 2.0 client in the Client ID field.

     

4. Enter the client secret used for the OAuth 2.0 client in the Client Secret field.

     

5. Enter the OAuth 2.0 URL used to initiate user authorization in the Authorization URL field.

     

6. Optional: If any additional optional parameters should be attached to the authorization URL, enter these parameters in the Authorization URL Parameters field.

   Authorization URL parameters must be entered in the format key1=value1&key2=value2.

   Properties such as client_id, grant_type, and client_secret do not need to be included in this field.

     

7. Enter the OAuth 2.0 token used to convert the request token into an access token in the Access Token URL field.

     

8. Optional: If any additional optional parameters should be attached to the access-token URL, enter these parameters in the Access Token URL Parameters field.

   Access-token URL parameters must be entered in the format key1=value1&key2=value2.

   Properties such as client_id, grant_type, and client_secret do not need to be included in this field.

     

9. Select the type of request method that should be used when sending requests to the OAuth 2.0 token URL from the Access Token URL Method pulldown menu.

   Typically, the access-token request method is set as POST.

     

10. Select the payload mode that should be used to send the OAuth 2.0 client ID and client secret with the token URL from the Authentication Payload Mode pulldown menu.

    • Encoded Header – The OAuth 2.0 client ID and client secret are attached to the authentication header as a Base64-encoded pair.
    • Form Data – The OAuth 2.0 client ID and client secret are attached as form-data payload parameters.
    • Query Parameters – The OAuth 2.0 client ID and client secret are attached to the token query as query parameters.
    • Skip Automatic Inclusion – This method should not be used with 3-legged OAuth 2.0 authentication.

      

11. Enter the token type that should be used to attach the OAuth 2.0 token to each request.

    Typically, the token type is set as Bearer, which indicates a bearer token. However, some API vendors use a different name or case.

      

12. Optional: If the OAuth 2.0 server requires additional scopes to be included with each token request, enter these scopes in the API scopes field.

    API scopes must be entered as space-separated values—for example, scope1 scope2 scope3.

    Nexla will automatically attach all entered scopes to each token request as a scope payload property.

      

13. Optional: If the access tokens received from the OAuth 2.0 server are short-lived, check the box next to "Requires Auto Refresh of Token" to configure Nexla to continuously automatically refresh the token to retain a valid access token.

      

    1. Enter the OAuth 2.0 token-refresh URL used to fetch a new access token using the current access and refresh tokens in the Refresh Token URL field.

       Typically, the token-refresh URL is the same as the OAuth 2.0 token URL.

         

14. Click to authorize the OAuth 1.0 client service via the UI.

      

15. Continue to Section 1.12.

1.11 Authentication: Token

Select this mode when the API server requires fetching a short-lived token before making authenticated calls to other endpoints.

1. Select "Token" from the Authentication Type pulldown menu.

     

2. Enter the username that should be sent with each request in the Username field.

     

3. Enter the password corresponding to the username in the Password field.

   Nexla will automatically combine the username and password into a Base64-encoded pair to be sent with each request.

     

4. Enter the URL used to fetch tokens from the API token server in the Fetch Token URL: URL to Get Token field.

     

5. Select the type of request method that should be used when sending requests to the token URL from the Fetch Token URL: HTTP Method pulldown menu.

   Typically, the token request method is set as POST.

     

6. Optional: If the token URL requires authentication information such as the username and password to be sent in a header with each token request, enter the name of the request header that should be used in the Fetch Token URL: Header Name for User/Pwd field.

     

7. Optional: If the token URL requires a payload to be sent with each token request, enter the request body in the Fetch Token URL: Request Body field.

   The token request body must be entered in a valid JSON object format.

     

8. Select the format of the response that will be received from the token URL from the Fetch Token URL: Response Format pulldown menu.

     

9. Enter the path to the token property within the response received from the token URL in the Fetch Token URL Response: Path to Token field.

   When plain is selected as the token URL response format, this field will not be shown. In this case, skip to step 10.

   • When json is selected as the token URL response format, enter the path to the token as a valid JSON Path input.
   • When xml is selected as the token URL response format, enter the path to the token as a valid XPath input.

     

10. Select whether the token generated by the token URL should be included in each API request as a request header or URL parameter from the Where to Add Token on API Requests pulldown menu.

      

    • When HEADER is selected:

      1. Enter the name of the header that will include the token in the Header Name for Token in API Requests field.

           

      2. Optional: If a prefix should be prepended to the header value, enter the prefix in the Header Prefix for Token in API Requests field.

           

      3. Optional: If the vendor requires a cookie to be included in API requests, check the box next to "Send cookie in a header?". This will configure Nexla to send a cookie in a request header along with the token.

           

    • When URL_PARAMETER is selected:

      1. Enter the name of the URL parameter that will include the token in the URL Parameter for Token in API Requests field.

           

11. Continue to Section 1.12.

1.12 Configure Validation Settings

Credential Validation

For API vendors that do not have a suitable endpoint for testing credential validity, see the information under Optional: Skip Credential Validation below.

1. Enter a URL from the API vendor that should be used to check whether or not the authentication mechanism works (based on the information entered in the preceding sections) in the Credential Validation: URL field.

   • The credential validation URL does not need to be the same as the endpoint URL with which this credential will be used.
   • Using an endpoint that does not incur a noticeable response delay from the API server is recommended—for example, fetch only one item if accessing an endpoint that returns an array of items.
   • To bypass credential validation without using the setting described under Optional: Skip Credential Validation below, enter any public endpoint.

     

2. Select the API method that will be used to execute the credential validation URL from the Credential Validation: API Method pulldown menu.

   Typically, the credential validation API method should be set as GET to fetch a record.

     

   • When GET is selected:

     1. Select the type of content that will be fetched from the validation endpoint URL during credential validation from the Credential Validation: Content Type pulldown menu.

          

   • When POST is selected:

     1. If the validation URL requires a payload during credential validation, enter the request body that will be sent in the Credential Validation: Request Body field.

        The request body must be entered as a valid JSON object.

          

     2. Enter the type of content that will be sent to the validation endpoint URL during credential validation from the Credential Validation: Content Type pulldown menu.

          

3. Section 1.13 provides information about advanced settings available for REST API credentials along with step-by-step instructions for configuring each setting.

   • To configure any desired advanced settings for this credential, continue to Section 1.13, and complete the relevant steps.
   • To create this credential without configuring any advanced settings, continue to Section 1.14.

Optional: Skip Credential Validation

Typically, a new REST API credential is validated during credential creation in Nexla. However, some APIs do not have a suitable endpoint for testing whether or not the information entered in the credential is valid. In this case, Nexla provides the option to skip credential validation during credential creation, avoiding the need to set test.url properties for these API vendors.

When credential validation is skipped at this point, credential validation will still be performed each time the credential is used with a data source/destination.

1. To skip credential validation during the credential creation process, check the box next to "Skip Credential Validation?".

     

2. Section 1.13 provides information about advanced settings available for REST API credentials along with step-by-step instructions for configuring each setting.

   • To configure any desired advanced settings for this credential, continue to Section 1.13, and complete the relevant steps.
   • To create this credential without configuring any advanced settings, continue to Section 1.14.

1.13 Advanced Credential Settings

This section provides information about the optional advanced settings available for REST API credentials, along with step-by-step instructions for configuring each of these settings.

1. Click to access additional available settings for the REST API credential.

     

2. Follow the instructions below to configure the desired advanced setting(s).

   • Additional Request Headers
   • Unsecure SSL Server Connection (Expired SSL Certificate)
   • JWT Authentication
   • HMAC Signature-Based Authentication
   • Shared Certificate Signatures

Additional Request Headers

1. If the API vendor requires additional request headers to be sent as part of each request, enter these request headers in the Headers field.

   Additional request headers must be entered as comma-separated values—i.e., header1:value1,header2:value2.

     

Unsecure SSL Server Connection (Expired SSL Certificate)

For connections to an API vendor with an expired SSL certificate, Nexla can be configured to allow an unsecure server connection by bypassing SSL certificate validation of the API endpoint.

1. To bypass API endpoint SSL certificate validation, check the box next to "Ignore SSL Certificate Validation?".

   Only enable this option if the API vendor's SSL certificate has expired.

     

JWT Authentication

Some API vendors require JSON Web Token (JWT)-based authorization as an added security layer in addition to normal authentication methods. For example, an API vendor that requires OAuth authentication may use the additional JWT assertion feature of the OAuth specification.

1. To configure this credential to support JWT-based authorization, check the box next to "Enable JWT Authentication?".

   Only enable this option if the API vendor requires the JWT authentication mechanism.

     

2. Enter the token URL that will be called to initiate JWT authentication in the JWT: Token URL field.

     

3. Enter the request body that will be sent to the JWT token URL in the JWT: Token URL Request Body field.

   The request body must be entered as a valid JSON object.

   The {token} macro can be used to dynamically substitute the JWT value.

     

4. Select the type of content that will be received from the JWT token URL from the JWT: Token URL Content Type pulldown menu.

   Typically, the content type is application/x-www-form-urlencoded.

     

5. Select the format of the token-request response that will be received from the JWT token URL from the JWT: Token Response Format pulldown menu.

   Typically, the response format is json or xml.

     

6. Enter the path to the token property within the token-request response in the JWT: Path to Token field.

   • When json is selected as the JWT token response format, enter the path to the token as a valid JSON Path input.
   • When xml is selected as the JWT token response format, enter the path to the token as a valid XPath input.

     

7. Enter the path to the token type property within the token-request response in the JWT: Path to Token Type field.

   • When json is selected as the JWT token response format, enter the path to the token as a valid JSON Path input.
   • When xml is selected as the JWT token response format, enter the path to the token as a valid XPath input.

     

8. Select the mode that will be used to include the generated JWT token in subsequent requests from the JWT: Token Include Mode pulldown menu.

     

   • When the token include mode is URL_PARAMETER:

     1. Enter the name of the URL parameter that will be used to sent the JWT token in each request in the JWT: Token URL Parameter field.

          

   • When the token include mode is HEADER:

     1. Enter the name of the request header that will be used to send the JWT token in each request in the JWT: Token Header Name field.

          

     2. Optional: If a header-type prefix should be prepended to the token header, enter the prefix in the JWT: Token Header Type Prefix field.

          

9. Enter the duration of JWT token validity in seconds in the JWT: Token Expiration Duration (Sec) field.

     

10. Optional: If the API vendor requires a secret key to be used when signing the JWT request and payload, enter the secret key in the JWT: Token Secret field.

      

11. Select the algorithm that will be used to generate the JWT token signature from the JWT: Signature Algorithm pulldown menu.

    Typically, the signature algorithm is HS256.

      

12. Enter the value of the scope claim used for token generation in the JWT: Scope Claim field.

      

13. Enter the value of the audience claim used for token generation in the JWT: Audience Claim field.

      

14. Enter the value of the issuer claim used for token generation in the JWT: Issuer Claim field.

      

15. Optional: If the API vendor requires one or more additional claims—beyond the standard audience, scope, and issuer claims—to be verified in each request, enter these claims in the JWT: Extra Claims field.

    Additional claims must be entered in a valid JSON object format.

      

HMAC Signature-Based Authentication

Some API vendors require each request to be signed with a signature generated using a custom HMAC algorithm.

1. To configure Nexla to sign each request with an HMAC signature, check the box next to "Enable HMAC Signature-Based Authentication?".

     

2. Enter the API key that will be used to sign requests in the HMAC: API Key field.

   This API key is provided by the API vendor.

     

3. If the API vendor also requires using an API secret for HMAC signature authentication, enter the API secret in the HMAC: API Secret field.

   Check the vendor's API documentation to determine whether an API secret is required.

     

4. Enter the signature-generator function that will generate the appropriate signature for each request in the HMAC: Signature Generator Function field.

   Currently, Nexla supports the Base64-Encoded Scala function for HMAC signature generation.

   For assistance with the input for this field, contact the Nexla Account Manager.

     

Shared Certificate Signatures

1. If the API vendor requires each request to be signed with a shared certificate, check the box next to "Sign Requests with Certificates".

     

2. Enter the content of the P12-formatted certificate file that will be used to sign each API request in the Client Certificate in P12 Format field.

   The P12-formatted certificate file typically consists of the private key and certificate chain.

   Open the certificate file with any text editor, and copy/paste its content into this field.

     

3. Enter the passphrase associated with the certificate file in the P12 PassPhrase field.

     

1.14 Save and Create the REST API Credential

1. Once all of the relevant steps in the above sections have been completed, click at the bottom of the Add New Credential screen to save the credential and all entered information.

2. The newly added credential will now appear in a tile on the screen and can be selected for use with a new data source or destination.

     

2. Data Source

To ingest data from an API endpoint using a Generic REST API credential, follow the instructions in Section 2 of Common Setup for REST API-Based Systems.

3. Data Destination

To send data to an API endpoint using a Generic REST API credential, follow the instructions in Section 3 of Common Setup for REST API-Based Systems.